Secure transaction method and system including biometric identification devices and device readers

ABSTRACT

The invention is directed towards methods, systems and apparatuses, see FIG.  1 , ( 100 ) for providing secure and private interactions. The invention provides capability for verifying the identity of a party initiating an electronic interaction with another party through data input module ( 140 ) which is verified by the identity verification module ( 150 ), which further includes a self-destruct mechanism ( 153 ). Embodiments of the invention include secure methods for conducting transactions and for limiting the transfer and distribution of personal data to only those data that are absolutely necessary for the completion of the transactions. The invention facilitates the transfer of additional personal data contingent upon an agreement that appropriately compensates the provider of the personal data.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to and is a divisional of U.S. patentapplication Ser. No. 10/148,512, entitled “Methods, Systems andApparatuses for Secure Transactions,” which is a U.S. national-stageapplication of PCT Application No. PCT/US00/42323, filed on Nov. 29,2000, entitled “Methods, Systems and Apparatuses For SecureTransactions,” which claims priority of U.S. Patent Application No.60/168,082 filed Nov. 30, 1999, entitled “Apparatus for ControllingConverged Media Systems Including Payment Applications, Using a Privacyand Security-Oriented, Customer-Centered Authentication Architecture forUsers of Pointing Identifying Devices and Biometrics PointingIdentifying Devices,” each of which is incorporated herein by referencein their entireties.

This application is related to U.S. Patent Application Attorney DocketNos. PRIV-002/02US 307640-2052, entitled “Biometric IdentificationDevice And Methods For Secure Transactions,” PRIV-002/03US 307640-2053,entitled “Biometric Identification Device” and PRIV-002/04US307640-2054, entitled “Biometric Identification Device And MethodsAssociated With Inventory,” each filed on the same date, and each ofwhich is incorporated herein by reference in their entirety.

FIELD OF THE INVENTION

The present invention relates to methods, systems, and correspondingapparatuses for providing secure interactions.

BACKGROUND

Most existing payment-processing and transactions-processing systemshave been designed by vendors, primarily to serve the vendors.Historically, the ability of a customer to use a payment option otherthan cash had been viewed as a sufficient concession to the customer.Non-cash payment systems put the vendor at risk of not receivingpayment, hence vendors and their associated financial institutions feltjustified in specifying stringent criteria for customers to use non-cashpayment systems. For face-to-face transactions at the point of sale, avendor would typically require a picture identification and/or adriver's license, together with a signature to accept a check drawn on alocal financial institution. For credit card purchases, a signature andsometimes a picture identification would be required. In both thesecases, the vendor, and his/her employees also have access to customeraccount information associated with the check or credit card.

Although most traditional vendors use the data provided to them by theircustomers only to secure the payment due to them from the transaction,the data collected has additional valuable potential, even if clearlyfraudulent activities—such as using the customer's credit-card data tomake unauthorized purchases—are not considered. For instance, a vendorcould track the frequency, amount, location, type, and other data aboutpurchases for each particular customer. This data could be used todevelop targeted advertising strategies designed to get the customerinto the store immediately and/or after a prolonged absence. Inaddition, mailing lists of customers could be developed that could besold to financial institutions or other vendors who want to promotetheir credit cards. Until recently, the cost and tedium involved incompiling and processing such data discouraged aggressive use ofpersonal data. However, due to recent technological advances, this hascompletely changed. Over the past several years, the plummeting cost ofcomputing hardware, and the increasing sophistication of datawarehousing and data mining software, in combination with exponentialgrowth in digitally-processed and internet-processed customer purchasetransactions, has put the security and privacy of the customer atextreme risk, despite contrary assertions of many vendors.

With the advent and growth of electronic commerce, the accelerating easeof compiling and processing such data has encouraged and emboldenedvendors to collect and exploit ever-greater amounts of personal datafrom their customers. The widespread use of Secure Sockets Layer (SSL)has dramatically improved the security of the personal and financialdata as it is sent from the customer to the vendor. Hence, untilrecently, many customers have been willing to provide the requested datawith little thought as to exactly what the vendor will do with the data.Many customers have little notion as to the value of that data. This isespecially true for commercial transactions that exploit the Internet.In such transactions data collection can be automated and theinformation gathered can be used in real time for targeted advertising.Despite strict privacy policies to the contrary, vendor-collectedcustomer data can (and often is) still sold to mailing lists, wherethese data and information can be used by companies with whom thecustomer has no desire to do business. Once customer data is public, thecustomer often has little or no recourse for retaining the privacy ofthat information.

According to The Forrester Report (April, 1999 published by ForresterResearch Inc.) 48% of both U.S. and European Internet retail companiesinterviewed indicated that they save customer name, address, and accountinformation for use in an express checkout system. Although such systemshelp to speed customers through checkout, many of the retail companiesadmitted, “[their] transactions systems have limited scalability, poorfraud detection, high ongoing costs, and lack of real-timeauthorization.”

Although retail companies that maintain these customer databases arguethat speedier checkout and even targeted advertising are in thecustomers' interests, the customer is often not clearly informed of whatinformation is being collected and stored and for what purposes.Removing oneself from a customer database, even when possible, can be atime-consuming process.

Perhaps one of the greatest concerns over the warehousing of customerdata and information is the highly lucrative target that such aconcentration of personal and financial information presents to hackersand other thieves. According to the Washington Post (“Cloaking DevicesDesigned for Wary Web Shoppers,” The Washington Post, Oct. 19, 2000,page E01), hackers stole 15,600 credit-card numbers from a Western Unionweb site during the month of September 2000. Credit card fraudrepresents a huge loss to both the credit-card industry and individualconsumers. An estimated 0.06% of point-of-sale credit-card purchases andas much as 1% of online credit-card purchases are fraudulent (“VISAShores up Web Position, Ends Fees on Theft of Credit Cards,” AmericanBanker, February, 2000; “Equity Research Report on First Data Corp.,”Morgan Keegan, January, 2000.). Other estimates by vendor symposia(e.g., the “Card Tech/Secure Tech” trade show on Dec. 1, 1999) estimatemuch higher figures, generally estimating that “Card Not Present”transactions experience 6 (six) times greater incidence of fraud thanactual physical “Card Present” transactions. Although most individualconsumers face limited financial liabilities if unauthorized use oftheir credit-card information is promptly reported, dealing withinstances of fraud can be frustrating and time-consuming.Notwithstanding, in the final analysis, all consumers eventually pay forcredit-card fraud in the form of higher vendor prices and lessattractive credit-card terms than might otherwise be available.

Numerous alternatives now exist for performing financial transactionsover computer networks.

Shawn Abbott (“The Debate for Secure E-Commerce,” Performance ComputingFebruary 1999) discusses both SSL and Secure Electronic Transactions(SET) protocols for electronic commerce. As stated in the article, “SSLis widely used because it is built into all major Web browsers andservers and is easy to apply.” However, beyond verifying that the vendoris a bona fide company and that the customer's computer is dealing withthe vendor's server, SSL protocol does little more than facilitateencrypted and reliable interaction between computers. On the other hand,SET is a messaging protocol specifically designed by financialinstitutions to facilitate bankcard transactions over open networks suchas the Internet.

To use SET, the customer has a digital certificate that is stored andencrypted using a pass phrase selected by the customer. A SET electronicwallet can be established by combining: (1) a digital certificate with(2) financial account information, (3) a private encryption key and (4)some additional software. To make a purchase, the vendor's server sendsa request to open the customer's SET wallet on the customer's computer.The customer is prompted for the pass phrase to authorize use of the SETwallet. After confirmation of the customer's pass phrase, paymentinstructions, including the customer's account data are bundled into anencrypted and protected message. The message is bundled in such a waythat the vendor cannot secretly access or tamper with it. The message,together with an authorization request by the vendor is forwarded to apayment gateway, which typically is a server at the vendor's financialinstitution. The messages are then decrypted off the open network andthe processing between financial institutions occurs as in standardcredit or debit card transactions. In the SET protocol all participantshold digital certificates rooted in a common SET key. Hence allparticipants are assured that the other participants have been approvedto act in their required roles.

The use of the SET protocol is more secure than the straightforward useof SSL. Its more widespread use has been slowed by the requirement thatspecial software is required to be installed by all participants andthat customers are required to be issued digital certificates. Inaddition, nagging worries about security still exist. Although eachdigital certificate is protected by a pass phrase, if the pass phrase iscompromised, unauthorized purchases can be made using the digitalcertificate. To address this issue, the SET protocol has built-incapability to accept digital certificates from personal tokens, such assmart cards. For smart cards to be used for Internet transactions, manymore computers require card-reading capability. Although the use ofsmart cards lessens the possibility of fraud, stolen smart cards couldbe used like stolen credit cards to impersonate the original owner.

According to Kenneth Kiesnoski (“Digital Wallets,” BankSystems+Technology, October 1999) both client-based and server-baseddigital wallets have a number of proponents. The digital wallet is anapplication that stores financial account information, account-ownernames, billing and shipping information, and other information thatmight typically be required to make an electronic transaction. At thecustomer's direction, all or part of this set of information istransferred to the vendor at the time of purchase. This saves thecustomer the trouble of typing all that information and possibly makingan error.

In a client-based digital wallet the application program resides on thecustomer's computer. One difficulty with client-based electronic walletsis their lack of portability. Every time the customer uses a differentcomputer, the information that had been stored in the digital walletmust be reloaded into the same or similar program on the currentcomputer. Another issue is that important personal and financialinformation resides on the client's computer. Traditionally, personalcomputers have not been particularly secure machines. Individuals withappropriate computer expertise who have physical access to a particularpersonal computer can generally extract information from it. Untilrecently, security breaches of personal computers from the outside weregenerally limited to viruses and worms embedded in downloads and emailmessages. Use of cable modems and other devices that facilitatecontinuous or near-continuous connectivity increases the probability foran increased number of security breaches of personal computers.

A server-based digital wallet resides on a server connected to theInternet. Most server-based digital wallets had been marketed by banksand did not accommodate information from cards issued by competingbanks. More recently, the trend has been shifting towards allowingmultiple cards backed by different organizations to be included in thedigital wallet. Server-based digital wallets provide more flexibilitythan client-based digital wallets in that they can be accessed from anycomputer. Presumably, server-based digital wallets are maintained oncomputers that are more secure than the typical personal computer,however the booty for a successful hacker is multiplied by the number ofregistrants whose information is stored on that server. In addition,each individual's data is protected only by a simple password, andmembers of the general public have been notoriously lax in choosing andmaintaining passwords.

Hardware developments are also proposed to enable more secure andflexible payments by computers.

Bob Curley (“Paying at the PC,” Bank Systems+Technology, October, 1999)discusses two systems designed to interact with personal computers.

The first is the UTM MACHINE, developed by UTM Systems. A user inserts acredit or debit card into the UTM MACHINE and then slides the UTMMACHINE with the inserted card into a floppy disk drive. The machineuses the heads of the floppy disk drive to read the magnetic stripe onthe credit or debit card. An Internet browser is then used to access aWorld Wide Web (WWW) page at the user's bank. The WWW page simulates theaction of an automated teller machine (ATM), complete with personalidentification number (PIN) authentication. Vendor identificationnumbers can be entered on the WWW page to transfer funds to a particularvendor.

The second hardware development discussed by Curley is the INTELLIPACK100, developed by NetPack. The INTELLIPACK 100 is a keyboard withbuilt-in credit card and smart card readers. Like the UTM MACHINE, thetransactions occur without transmitting financial account information tothe vendor. These hardware developments can make Internet transactionsalmost as secure as point-of-sale financial transactions.

Additional hardware developments are further improving the security ofall credit and debit card transactions.

In “The Biometrics White Paper,” Ashbourn discusses a large number ofgeneric issues associated with biometric identification for use insecurity applications. Ashbourn defines biometrics “as measurablephysiological and/or behavioral characteristics that can be utilized toverify the identity of an individual. They include fingerprints, retinaland iris scanning, hand geometry, voice patterns, facial recognition andother techniques.” Our use of the term “biometrics” and related forms ofthe word are intended to be consistent with the above-quoted definition.However, an individual's written signature and/or handwriting are not tobe considered biometrics in the context of this application.

The Ashbourn paper also contains reviews of some particular productsthat are currently or will soon become commercially available.

Precise Biometrics, in cooperation with iD2 Technologies and Miotec Oyis developing technology to enable the use of a fingerprint to enhancethe security of Internet transactions. Information on their web site issketchy, but their proposed scheme apparently uses a smart card and aseparate reader that is connected to a personal computer. The smart cardwould be inserted into the separate reader, which would read thefingerprint data and send the data to the smart card chip. The chip onthe smart card would compare the fingerprint with the stored templateand if they match, send off an Internet order. The use of a separatereader reduces the flexibility of the approach.

In U.S. Pat. No. 6,011,858 by Stock et al., a programmable memory cardis adapted to hold personal information of a user and includes abiometric template of a physical characteristic of the user. The patentalso discloses a biometric verification system that includes a biometricscanner configured to generate a biometric template based on a physicalcharacteristic of a user. The biometric scanner is also configured toverify each user's live physical characteristic against the biometrictemplate of the physical characteristic stored on the memory card. Aprogrammable memory card reader is also used. The programmable memorycard reader is in communication with the biometric scanner and isconfigured to receive a memory card and to communicate with thebiometric scanner to store the biometric template generated by thebiometric scanner to the memory card. The memory card reader is alsoconfigured to retrieve the biometric template stored on the memory cardand to ensure the security of the information that relates to theapplications stored on the card. As with the Precise Biometricsapproach, the separation of the biometric scanner from the smart cardreduces flexibility of the system.

In U.S. Pat. No. 6,084,968 by Kennedy et al., an apparatus and methodare described for providing multiple secure functions in a host orwireless radiotelephone. The determination of the secure function isdetermined by credential information carried on a smart card or securitytoken. To provide for an authentication function, the smart card maystore biometric features of a user. As in the previous patent, the smartcard is separate from the device that obtains the live biometric.

In U.S. Pat. No. 6,016,476, Maes et al. describe a portable informationand transaction processing system that uses biometric authorization anddigital certificate security. The system requires the use of a personaldigital assistant (PDA) in which the user stores his or her financialand personal information.

SUMMARY OF THE INVENTION

Selected embodiments of the invention address and resolve variousaspects of the abovementioned difficulties as well as other issues thatwill be set forth in part in the description that follows, and in partwill be obvious from the description, or may be learned by the practiceof the invention. No particular embodiment is required to solve any oneparticular problem set forth above or below. Rearrangements ofcomponents in ways not explicitly described but which would be obviousto a skilled practitioner of the art are included in the broad scope ofthe invention.

This invention empowers customers to retain more control over theirpersonal data. Preferred embodiments of the invention provide the vendorwith stronger assurances of receiving any non-cash payment, but limitthe personal data accessible to the vendor. In various preferredembodiments, personal data provided to the vendor in excess of thatrequired to assure payment are provided in return for some valuableconsideration.

For example, a customer may wish to purchase a deliverable, which wedefine as any property, goods, or services that the customer may receivein return for some valuable consideration (other property, goods,services, or money). The deliverable has a price, typically a monetaryvalue, although the price could be set in terms of other forms ofvaluable consideration. In this example, some party has an interest inreceiving personal data about the customer. In preferred embodiments,this party is either the manufacturer or the vendor of the deliverable,although the precise relationship of this party to the transaction isnot important. For instance, the party may be an affiliate of the vendoror manufacturer or may be a company that has a contract with the vendoror manufacturer. The category of personal data desired will be called apersonal data field. For instance, a customer name would be a personaldata field. The value of that personal data field is the specificcustomer's name, for example, Jones.

In one preferred and illustrative embodiment of the invention, a partyreceives from the customer a value for at least one prescribed personaldata field. The value of the at least one prescribed personal data fieldis certified as corresponding to the customer. Finally, the price of thedeliverable is reduced by a prescribed discount. The prescribed discountis independent of the value of the prescribed personal data field. Thediscount depends only on the fact that the customer has provided a valuefor the prescribed data field. For instance, the discounter may offer afirst discount to any customer from whom the discounter receives an agethat is certified as belonging to the customer. Regardless of the valueof the age, the discounter must provide this first discount. A seconddiscount might, for instance, be available to customers over age 65. Theaddition of the second discount does not negate the fact that the firstwas provided without regard to the customer's age.

Other embodiments of the invention involve methods by which a paymentmay be conveyed from a payer to a payee by means of a financialinstitution or other financial intermediary. The words “payer” and“payee” are intended to be very general terms to identify the partymaking the payment (the payer) and the party receiving the payment (thepayee). In typical circumstances, the payee is a vendor and the payer isa customer, although the payment method is intended to be inclusive ofarrangements that include multiple additional parties.

The term financial intermediary is intended to cover a broad range ofentities. The term includes not only traditional financial institutionssuch as banks, credit unions, savings and loans organizations,credit-card companies, and the like, but also includes privatecompanies, private account vendors, private trusts, private reserves,private depositories, private escrow services, individual persons or anyother designated entity, and the like, that can legally maintainaccounts and transfer monetary value between accounts. The transfer ofmonetary value between accounts includes transfers wherein the accountsare maintained in separate financial intermediaries as well as transfersin which the accounts are maintained in the same financial intermediary.

Preferably, the financial intermediary is an entity and/or person(s)bilaterally agreed upon and bilaterally trusted by both the payer andthe payee to serve as an escrowing agent, transaction agent, transactionconduit, or other enabling means for moving payments, credits, etc. tothe payee account or destination of choice, from the payer account orsource of choice.

One embodiment of a method by which a payer conveys a payment to a payeeinvolves receiving payer payment information from the payer. The payerpayment information includes at least three pieces of information: theaddress of the payer's financial intermediary, payer account data thatspecifies a payer account from which payment is to be made, and apersonal identifying device control designation.

The address of the financial intermediary can take any or several ofmany forms. The address could be a physical address to which physicalmail or packages could be sent. The address could also be an address onan open computer network, such as the Internet, or a routing address fora closed computer network, such as the proprietary banking network nowin use. In other embodiments, the address of a financial intermediary isa phone or fax number. The address could be the name of the financialintermediary if information as to where to send data could be determinedfrom other sources. In general, the address of the financialintermediary includes any information from which an appropriatedestination for sending data could be determined. Because only anaddress is required, the actual identity or identities of the financialintermediary or intermediaries is neither mandatory, nor necessarilyrevealed.

The payer account data specifies from what account the payment is to bemade. The payer account does not need to be of any special type. Forinstance, it can be a checking account, a saving account, a money-marketaccount, a credit-card account, or the like, or any other appropriateaccount. The account data may include a single account or severalaccounts associated with the payer. References to the payer account areintended to include either a single specified account or a set ofaccounts. For instance, the payer account data might specify that acertain percentage of the payment be funded from a specified checkingaccount and the balance be funded from a specified credit-card account.This combined payment should be understood as being made from the payeraccount. In cases using multiple accounts to fund such a transaction,multiple payer financial intermediaries may be called on to participate,thus, multiple payer financial intermediary addresses might be involved.These more complex cases are included within the scope of the invention.

The personal identifying device control designation is an identifyingsequence of data given to a personal identifying device (PID).Preferably, the identifying sequence of data is a string of ASCIIcharacters although a pure data stream with no corresponding ASCIIequivalent can also be used. In many preferred embodiments, the PIDcontrol designation is unique to each PID. However, in some embodiments,the PID control designations are not unique. For instance, a group ofPIDs issued to a single company might all have the identical PID controldesignation. PIDs will be discussed in considerably more detail later.

For the purpose of this method of payment, a PID is a portable devicethat authenticates that a user of the device is privileged to make apayment from the payer account(s) specified in the payer account data.As used in the context of a PID, the word “portable” means that the sizeand weight of the PID is such that an individual can conveniently carrythe PID on his/her person.

The issue of whether the user is privileged to make a payment from thepayer account(s) is internal to the PID. For example, a family PID mightauthenticate that a child is privileged to use the PID, but is onlyprivileged to request that a payment be charged to some accounts, butnot others. This matter of privilege is internal to the PID and does notextend to any requirement that the PID actually confirm with the payerfinancial intermediary that the person requesting that the payment becharged to a particular account is considered authorized to do so by thefinancial intermediary. Such additional confirmation by the PID isincluded in some embodiments of the methods, but not in others. Thevarious methods of confirming that the user of the device is privilegedto make a payment from the payer account will be discussed later.

After receiving the payer payment information, some embodiments involveconfirming that the PID has been registered in the name of the payer andthat the device is privileged to access the payer account. In theseembodiments, a payee payment packet is formed that includes the payeraccount data, payee account data and a payment amount. The payee accountdata, like the payer account data, may be either a single account or aset of accounts with instructions as to how the payment is to be dividedbetween the accounts. The payee payment packet is sent to the payerfinancial intermediary address. In some embodiments this step is donedirectly, that is, the payee payment packet is sent directly to thepayer financial intermediary address. In other embodiments, the payeepayment packet is sent indirectly to the payer financial intermediaryaddress, possibly forwarded by one or more trusted financial (ornon-financial) intermediaries. In principle, any other trusted partymight be designated to initially receive the payee payment packet.Eventually, payment will be accepted from the payer financialintermediary or intermediaries in the case of multiple financialintermediaries. Acceptance of payment from the payer financialintermediary includes the case in which the payer financial intermediarydeposits funds (or some corresponding value) in the payee account at apayee financial intermediary.

In other embodiments, the PID is not immediately confirmed as beingprivileged to access the payer account and registered in the name of thepayer. In many of these embodiments, the payee payment packet includesthe PID control designation and confirmation of the PID privileges canbe done anytime thereafter.

Alternative embodiments of the invention eliminate the directinvolvement of a financial intermediary by making and funding thepayment in the form of a bearer financial instrument or the like. Thebearer instrument can assume either a familiar, conventional paperserial-numbered certificate form, an electronic digitalcertificate-based form, or other custom bearer instrument form.

Yet other alternative embodiments of the invention include multipledifferent methods for a customer to make a purchase from a vendor. Thesemethods involve customer authentication of his or her identity to a PID.If a PID user is identified by a PID as privileged to use that PID, andif the user is also privileged to request that a proposed payment becharged to the customer account, then the PID transfers the customeraccount data and the customer financial intermediary address to aninformation processor. In turn, the vendor transfers vendor account dataand the payment amount to the information processor. The informationprocessor is a component that receives signals from both the customer(payer) and the vendor (payee). A vendor payment packet is formed thatincludes the customer account data, the vendor account data, and thepayment amount. The vendor payment packet is sent to the customerfinancial intermediary address. As with the payee payment packet ofearlier embodiments, the vendor payment packet may be sent to theappropriate financial intermediary address either directly orindirectly. The customer account is debited by the payment amount plus acustomer surcharge and the vendor account is credited by the paymentamount minus a vendor surcharge. Either or both the customer surchargeand the vendor surcharge may range from zero to any amount, depending onthe embodiment and/or on the surrounding transactional situation andenvironment.

Additional embodiments of the invention include generic methods for acustomer to conduct a transaction. Some of these embodiments comprisethe steps of: authenticating the customer identity to a PID, sendingcustomer account data to a receiver, and receiving acknowledgment thatthe transaction was approved. The receiver can be any device capable ofreceiving customer data from a PID.

Other embodiments of the invention include methods of interacting with a“simulated inventory”. A simulated inventory is defined for the purposesof this application and according to this invention, as a visualrepresentation of a catalog, index, directory, or other content. Thecontents of the simulated inventory are not limited in this invention.

The visual representation includes all kinds of visual representations,including two-dimensional displays or projection images,three-dimensional displays or projection representations usingperspective for the third dimension, and holographic representations. Inmost embodiments, the visual representation involves a pictographicgraphical user interface in which the user virtually travels, orequivalently perambulates, through the simulated inventory bymanipulating a cursor. In this application, the term “cursor” includesall displayed control indicia. Typically a cursor is represented by anarrowhead although other representations are used. In some embodimentsthe cursor is represented by an “avatar” (an icon or representation of auser in a sharable virtual reality environment). Using the cursor, (orin some embodiments, the avatar), the customer can travel about thedomain of the simulated inventory, browse the inventory, command anyinventory item to detail its properties (sizes, price, etc.), fill ashopping basket or other purchase enabler, and atend-of-shopping-session, pay for the selected item(s).

In one preferred embodiment of a simulated inventory using such agraphical user interface, a multiplicity of such icons are used torepresent elements in the inventory. The phrase “graphical userinterface” is to be interpreted broadly in this application. The phrase“holographic graphical user interface” will be understood to be a subsetof graphical user interfaces and will be used in embodiments in whichholographic representations are used similar to two-dimensionalgraphical user interfaces. All these methods for a user to interact witha simulated inventory include the step of authenticating a user to aPID. The authenticated user provides inputs to the PID allowing the userto travel at any speed they choose through the simulated inventory.

Embodiments of the invention also include systems by which a payerconveys a payment to a payee. Some embodiments of such systems include aPID that transmits signals to an information processor. These signalsinclude the payer account data and the payer financial intermediaryaddress. The information processor receives signals from both the PIDand from the payee. The signals from the payee include the payee accountdata and the payment amount. The information processor then forms apayee payment packet that includes the payer account data, the payeeaccount data, and the payment amount, and sends the payee payment packetto the payer financial intermediary address. The payee payment packetcan be sent to the payer financial intermediary address either directlyor indirectly, that is, the payee payment packet might be forwarded toone or more intermediaries before arriving at the payer financialintermediary address.

Other embodiments of the invention include verification systems.Embodiments of verification systems comprise: (1) an “actuator” forperforming a user-initiated action, (2) a PID that transmits signalsthat encode an identification and an instruction that one or moreuser-initiated actions be taken, and (3) a verification processor thatreceives the signals from the PID and verifies that the identificationis associated with a PID that is authorized to request that the one ormore user-initiated actions be taken.

After verification, the verification processor signals the actuator toperform the user-initiated action. In preferred embodiments, theidentification is the PID control designation, but the term“identification” is intended to be interpreted broadly. The term“actuator” should also be interpreted broadly. The actuators envisionedinclude those that result in mechanical actions and/or electricalactions, as well as those that result in actions that only involvetransfer or manipulation of data.

Still other system embodiments of the invention include simulatedinventory systems. Simulated inventory systems include: (1) a “simulatedinventory display”, (2) a simulated inventory controller that controlsthe interaction of at least one cursor interacting with at least oneicon on the simulated inventory display, and (3) a PID that transmitsinstructions to the simulated inventory controller.

As illustrated above, numerous embodiments of the present inventioninclude the use of a PID. A PID, generally, is a portable device thatauthenticates that any user of the device is privileged to use thedevice, plus, is authorized to request that particular actions be taken.The particular actions to be taken can vary with individual embodiments,but typical actions include, but are not limited to:

initiating a purchase or payment, either over an electronic network orat a vendor-operated sales site (including conventional stores, mobilevendors, service providers, flea markets, etc.);

interacting with a graphical user interface, which may include actuatingdisplayed icons on a screen or monitor;

permitting entry into buildings, homes, automobiles, and other locationsthat need protected entry capabilities;

making a telephone call, including, but not limited to a voice call, adata call, an electronic mail call, an Internet Service Provider call,an Internet URL portal call, or other URL access call;

logging onto a computer;

initiating a session at an information kiosk; and selecting restrictedentertainment options (such as pay-per-view television or televisionprograms that may contain material that would be inappropriate forcertain members of a household).

Preferred PID embodiments comprise: a transmitter for sending signals, auser input module for receiving input from a user, a personal datastorage medium, an identity verification module, and at least oneprocessor. The processor, or multiple processors, depending upon thedetails of the design, couple the various components and in someembodiments perform some of the functions assigned to the othercomponents. For instance, the identity verification module includes averification input component, an identity data module for storing atleast one set of stored identity data, and a comparator that comparesthe user identity data with stored identity data. One or more of theprocessors may perform the function of the comparator.

Many preferred embodiments of PIDs authenticate a user through the useof a biometric. This type of embodiment is referred to as a “biometricpersonal identifying device” (BPID). In a BPID, the stored identity datawould be considered a biometric template and the verification inputcomponent would collect a live biometric sample, which will typically bereferred to as a biometric sample. As discussed by Ashbourn, we will usethe phrase “biometric template” and variations thereof to refer to areference sample of a chosen biometric against which a future livebiometric sample is compared. Preferably, neither the biometric templatenor the biometric sample is available outside the BPID. Keeping thesedata local to the BPID reduces the chance that an individual's biometricbecomes accessible to the public.

In this application, the acronyms PID (personal identifying device) andBPID (biometric personal identifying device) are used extensively. In aprior provisional application (Ser. No. 60/168,082, filed Nov. 30,1999), entitled, “Apparatus for Controlling Converged Media SystemsIncluding Payment Applications, Using a Privacy and Security-Oriented,Customer-Centered Authentication Architecture for Users of PointingIdentifying Devices and Biometrics Pointing Identifying Devices,” whichis incorporated by reference herein in its entirety, these same acronymsrefer to “Pointing Identifying Device” and “Biometric PointingIdentifying Device.” The PID and/or BPID discussed herein, aregeneralizations and extensions of the specific embodiments of PointingIdentifying Devices and Biometric Pointing Identifying Devices discussedin the provisional application. In particular, as will be furtherdiscussed herein, the “pointing” capability of the original PointingIdentifying Device and Biometric Pointing Identifying Device need not bepresent in all embodiments of PIDs and/or BPIDs. Even in the provisionalapplication, the pointing capability of the devices was not required forall embodiments of the invention. The devices called PIDs and BPIDs inthe provisional application should be interpreted as specificembodiments of the more general PIDs and BPIDs discussed herein.

Various embodiments of the invention also include an informationprocessor. Embodiments of an information processor comprise: (1) atleast one processor, (2) a receiver for receiving customer data from aPID, (3) a vendor connection that enables the transmission of vendoraccount data to the information processor, and (4) a financialintermediary connection(s) that facilitates the transmission of vendoraccount data and customer account data to a financial intermediary.Preferred embodiments of information processors will be discussed later.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings illustrate complete embodiments of theinvention in which:

FIG. 1 shows a schematic of an embodiment of a PID.

FIG. 2A illustrates a barcode reader coupled to a PID. FIG. 2Billustrates a magnetic stripe reader coupled to a PID.

FIG. 3 shows a schematic of an embodiment of a BPID.

FIG. 4 shows a schematic of an embodiment of an information processor.

FIG. 5 illustrates a schematic of an embodiment of a verificationprocessor.

FIG. 6 illustrates a schematic of a verification system.

FIG. 7 shows a schematic of a system by which a payer conveys a paymentto a payee.

FIG. 8 illustrates a schematic of a simulated inventory system.

FIG. 9 shows a method for discounting a deliverable.

FIG. 10 illustrates a method by which a payer conveys a payment to apayee.

FIG. 11 shows another embodiment of a method by which a payer conveys apayment to a payee.

FIG. 12 illustrates a method for a customer to make a purchase from avendor.

FIG. 13 illustrates a method for a customer to conduct a transaction.

FIG. 14 illustrates a method for interacting with a simulated inventory.

Reference numerals used in the drawings refer to the correspondingcomponents listed below unless otherwise specified.

-   -   100 personal identifying device (PID)    -   110 processor    -   120 transmitter    -   125 transceiver    -   130 receiver    -   140 user input module    -   142 joy stick    -   144 activation button    -   146 mode switch    -   148 slide bar    -   149 positional sensor    -   150 identity verification module    -   152 identity data module    -   153 self-destruct element    -   154 comparator    -   156 keypad    -   160 data storage medium    -   170 display device    -   180 power source    -   190 biometric input device    -   200 biometric personal identifying device (BPID)    -   210 kill switch    -   220 bar-code reader    -   230 magnetic-stripe reader    -   300 information processor    -   310 processor of the information processor    -   320 information transmitter    -   330 information receiver    -   340 vendor connection    -   350 financial intermediary connection    -   360 certification repository connection    -   400 verification processor    -   410 processor of the verification processor    -   420 verification processor transmitter    -   430 verification processor receiver    -   460 certification repository connection    -   470 actuator connection    -   500 verification system    -   510 actuator    -   600 financial intermediary component    -   610 payee    -   620 certification repository database    -   650 simulated inventory system    -   660 simulated inventory controller    -   670 simulated inventory display    -   710 steps in determining prescribed discount and prescribed        personal data fields    -   712 step of specifying customer benefit function    -   714 step of specifying customer non-negotiable constraints    -   716 step of specifying customer benefit function normalization        value    -   720 step of maximizing a function subject to constraints    -   722 step of specifying discounter benefit function    -   724 step of specifying discounter non-negotiable constraints    -   726 step of specifying discounter benefit function normalization        value    -   730 step of receiving values for prescribed personal data fields    -   740 step of certifying that the value of a personal data field        corresponds to the customer    -   750 step of reducing the price by the prescribed discount    -   810 step of receiving payer payment information    -   820 step of confirming the PID control designation    -   830 step of forming a payee payment packet    -   835 step of sending the payee payment packet to payee financial        intermediary    -   840 step of sending the payee payment packet to payer financial        intermediary    -   850 step of accepting payment    -   910 step of receiving a payee payment packet    -   920 step of debiting the payer account    -   1010 step of selecting items for purchase    -   1020 step of adding selected items to electronic shopping cart    -   1030 step of determining the payment amount    -   1040 step of authenticating the customer identity to a PID    -   1050 step of transferring data from the PID to the information        processor    -   1060 step of transferring data from the vendor to the        information processor    -   1070 step of forming a vendor payment packet    -   1080 step of sending the vendor payment packet to the vendor        financial intermediary    -   1090 step of sending the vendor payment packet to the customer        financial intermediary    -   1100 step of debiting the customer account    -   1110 step of crediting the vendor account    -   1210 step of selecting items for purchase    -   1220 step of adding selected items to electronic shopping cart    -   1230 step of determining the payment amount    -   1240 step of authenticating the customer identity to a PID    -   1250 step of sending customer data to a receiver    -   1260 step of receiving acknowledgement that the transaction was        approved    -   1310 step of selecting items for purchase    -   1320 step of adding selected items to electronic shopping cart    -   1330 step of determining the payment amount    -   1340 step of authenticating the customer identity to a PID    -   1345 step of certifying payment capability    -   1350 step of traveling through the simulated inventory

DETAILED DESCRIPTION

Having summarized the broad nature of the invention above, this sectionwill focus on detailed descriptions of various preferred embodiments.Unless specifically stated otherwise, the vocabulary defined previouslyis intended to apply herein.

Referring now to the drawings, FIG. 1 shows a schematic of a preferredembodiment of a PID 100, which is shown enclosed by the outer boundary.Preferably, the elements indicated in FIG. 1 are integrated in a singleunit, preferably supported by an external housing. The PID 100 comprisesa processor 110 that processes signals from the various components andcontrols the operation of the PID 100. One or more processors 110 may beused, depending upon the details of the device. In various embodiments,the processor 110 processes the signals according to one or morealgorithms that are loaded as software, firmware, or are hardwired intothe processor 110. Although an electronic microprocessor is thepreferred processor 110, all types of processors that can processsignals are included within the meaning of the term processor. Forinstance, fluidic and optical controllers, properly configured, canoperate as one or more processors in various embodiments.

The preferred PID 100 also includes a transmitter 120 for transmittingsignals and a receiver 130 for receiving signals. The receiver 130 isnot included in some PID embodiments, although most preferredembodiments include the receiver 130. In some preferred embodiments, thetransmitter 120 and the receiver 130 are combined into a transceiver inwhich at least some components of the transmitter 120 and the receiver130 are used in both the transmitter 120 and the receiver 130. Suchembodiments should be considered as having both a transmitter 120 and areceiver 130 even though some or all of the components are shared.Transceivers are most likely to be used with radio-frequencytransmitters and receivers. The particular types of transmitter 120 andreceiver 130 are not critical to the PID 100. Embodiments employingradio-frequency (RF), infrared (IR), microwave, optical, or ultrasonictransmitters and receivers are likely to be most commonly used. Althoughwireless transmission and reception are preferred, transmitters andreceivers that communicate via wires or wave-guides are included in themeaning of transmitters and receivers.

In many embodiments both wired and wireless transmitters and receiversare provided. For instance, when used in conjunction with a computer,the PID 100 might be connected to the computer through an RJ-11 phonejack in the PID 100 and the computer's phone jack. Alternatively, aUniversal Serial Bus (USB), serial port, or parallel port connection maybe used to provide a wired connection to the computer. The wiredalternatives might be particularly useful in electronically noisyenvironments. Preferably, signals received by the receiver 120 andsignals transmitted by the transmitter 130 are encrypted. Preferably, anasymmetric encryption scheme, such as a public key/private key scheme isused. In particular, the RSA algorithm (which is described in detail inSchneier, B. C., Applied Cryptography—Protocols, Algorithms, and SourceCode in C, Second Edition, John Wiley and Sons, Inc., New York, N.Y.,1996, which is incorporated herein by reference) is one preferredapproach for encrypting information transmitted and received by the PID100. However, other encryption schemes may be used in alternativeembodiments.

A user-input module 140 includes at least one input mechanism thatenables a user to indicate what action is to be taken. In the preferredembodiment illustrated in FIG. 1, the user-input module 140 includes ajoystick 142, an activation button 144, various mode switches 146, aslide bar 148, and a positional sensor 149. Preferably the joystick 142is sized to be operable by a thumb of the user. The activation button144 preferably is used to indicate that an action should be taken. Theactivation button 144 is preferably mounted on the joystick 142 and isused in conjunction with a graphical user interface (GUI) much like abutton on an electronic mouse is used. The mode switches 146 are one ormore switches that alter the meaning of the user's input according tothe setting of the switch. Extensive examples of the use of modeswitches are provided in U.S. Pat. No. 5,481,265, which is included inits entirety by reference herein. Slide bar 148 allows for a user inputthat is proportional to the distance of the bar from one end of itsrange. Such an input device can be implemented as a variable resistor ora variable capacitor. Alternatively, slide bar 148 can include multiplediscrete settings, each of which represent a different control level orcontrol selection (such as high/medium/low/off). Positional sensor 149(which can be implemented as a tilt sensor, a mobile global positioningsystem (GPS) unit or any other technology for determining orientation ofthe device) provides information as to the spatial orientation of thePID. The positional sensor 149 is implemented in any fashion known tothose skilled in the art that is appropriate for a particularimplementation. The user-input module 140 shown in FIG. 1 is just oneexample of many possible configurations by which the user can enterinformation into the PID 100.

Other embodiments may include additional input mechanisms, such as akeypad, a pressure-sensitive surface, a scroll wheel, a bar-code reader,a radio-frequency-tag reader, accelerometers to provide direction ofmovement and acceleration information of the device, or amagnetic-stripe reader, either individually, or in combination with oneor more of the input mechanisms described above. Any or all of these maybe integral to the PID 100. In summary, user-input module 140 requires:(1) at least one input mechanism; (2) may include (but is not limitedto) multiple of the aforementioned input mechanisms; and (3) may includeany other connectable, feasible input mechanism, including some notmentioned herein.

A personal data storage medium 160 stores personal data, and optionally,other data. The personal data storage medium 160 is preferably an easilyre-writable medium, such as a magnetic or optical disk or tape. Othernon-volatile memory devices such as a Programmable Read Only Memory(PROM), (which can only be written once), an Erasable PROM (EPROM), oran Electronically Erasable PROM (EEPROM) are also suitable. In someimplementations, (as with the PROM), the personal data storage medium160 is not re-writable and must be physically replaced when personaldata that is stored on the personal data storage medium 160 changes.

An important part of the PID 100 is an identity verification module 150.The identity verification module 150 comprises an identity data module152 for storing at least one set of stored identity data, a verificationinput component (shown in FIG. 1 as a keypad 156), and a comparator 154that compares the user identity data obtained by the verification inputcomponent with at least one set of stored identity data and signals aprocessor 110 as to whether the inputted user identity data sufficientlymatch at least one set of stored identity data. In operation, in theembodiment illustrated in FIG. 1, the user identity data can be conveyedby a series of keystrokes entered on the keypad 156. The comparator 154would determine if the inputted series of keystrokes match a series ofstored keystrokes corresponding to a particular authorized user. Whethera match is found, or not, would be communicated to the processor 110.

In some embodiments, the comparison is performed by processor 110. Insuch embodiments, both the comparator 154 and the processor 110 are bothto be considered present, in spite of both elements being embodied inthe same physical component.

If the comparator 154 determines that a match exists, the processor 110would allow the user to initiate or continue taking actions that aredetermined by the user inputs received from the user input module 140,possibly in combination with signals received from the receiver 130.Such actions would be communicated to the transmitter 120 fortransmittal to some other device.

If a match is not found, the processor 110 can initiate an appropriaterecovery tactic, exception condition tactic, or course of action basedon software, firmware, or hardware alarm routines associated with thepre-determined operational policies, enabled and executed by processor110. For instance, the processor 110 can be used to print a message on adisplay device 170, requesting that the user try again, oralternatively, a kill switch 210 could be activated, which (ifimplemented) could be used to cut off communication of the device,either by means of disabling the transmitter 120 and/or the receiver130. Alternatively, a beeper (not shown) or a voice message (not shown)could alert the user of his/her error. Although the kill switch 210 ispreferably located so as to interrupt data flow to and from thetransmitter 120 and the receiver 130, other embodiments locate the killswitch 210 in alternative or additional locations, such as between theprocessor 110 and the user input module 140.

Further applications of a kill switch 210 and various types of securitysystems that might be included in various embodiments of a PID 100 aredescribed in U.S. Pat. Nos. 5,481,265 and 5,729,220, both to Russell,both which are included herein by reference in their entireties. Ingeneral, a kill switch 210 is a mechanism for immediately revokingsecurity privileges that had been granted and terminating an interactivesession between a PID 100 and a device exchanging signals with the PID100. The kill switch 210 is not required to be part of a PID 100.

Although a display device 170 is not required, it is preferably includedas part of a PID 100. When a display device 170 is included, preferablyit is a liquid crystal display, although other types of display devicesare used in some embodiments.

Preferably, the PID 100 carries its own power source 180, which mostpreferably includes one or more electrical batteries. Alternatively oradditionally, for very low power applications, a bank of capacitorscould be used. Alternatively or additionally, power can be fed to thePID 100 via cables, or in some embodiments is wirelessly beamed to thePID 100 from some other device.

Preferably, the PID 100 is portable, meaning that the size and weight ofthe PID 100 is such that an individual can conveniently carry the PID100 on his/her person. For example, a PID 100 preferably is sized sothat when it is not in use, it can be conveniently carried using atleast one of the following: a handbag, a book bag, a belt strap, apocket, or a wrist strap. Preferably the PID 100 weighs less than twoounces (about 57 grams). Most preferably, the PID 100 weighs less thanone ounce (about 28 grams). Preferably the volume is the PID 100 is lessthan two cubic inches (about 32 cubic centimeters). Most preferably thevolume of the PID 100 is less than one cubic inch (about 16 cubiccentimeters).

Because of the sensitivity of the user identity data stored on theidentity data module 152, preferably the identity data module 152 can becoupled to a self-destruct element 153 that destroys the identity dataif unauthorized access to the stored identity data is attempted. Forinstance, the PID 100 can be built so as to render the identity dataunreadable if identity data module 152 is probed by anyone but aqualified technician who follows a pre-determined sequence of actions.Additionally or alternatively, in some preferred embodiments, protectivepackaging tactics can be used to protect some or all of identityverification module's 150 components. One typically used delicateelectronics protection tactic is known as “conformal coating”. In thisapproach, an extremely thin polymer or rubber-like “shrink wrap” iscompletely superimposed over the electronic components to be protected.Attempts by any unauthorized party to gain physical access to theconformal coating-protected electronics will usually result in thedestruction of the coating-protected electronics. In some embodiments,the identity data module 152 is combined with the personal data storagemedium 160. In such embodiments, both elements are considered to bepresent, in spite of the fact that they share a single physical device.

Alternative embodiments include auxiliary input mechanisms. FIG. 2Ashows a bar-code reader 220 and FIG. 2B shows a magnetic-stripe reader230. In both these embodiments, the auxiliary input mechanisms areattached via a cable to the PID 100, although they may communicate withthe PID 100 through a wireless system. In some preferred embodiments,such auxiliary input devices are implemented with microminiaturizedcomponents that simply plug into the PID 100.

Additional auxiliary input mechanisms, such as radio frequency (RF) tagreaders can also be incorporated. RF tag readers can include technologythat reads RF tags and/or RF signatures. RF tags emit a bit stream wheninterrogated while RF signatures reflect a unique RF signature whenradiated with RF energy.

In some advanced versions of the PID 100, optional embodiments includethe capacity to provide other data and signal outputs beyond theabovementioned outputs of transmitter 120. Such embodiments can provideadditional functions, e.g., bar-code writer and magnetic-stripe writeroutputs, targeted for use with auxiliary output destination mechanismssuch as “PID-readable/writable” smart shelf labels or smart productlabels” (in conjunction with PID-initiated bar-code reader/writerfunctions) (not shown) and/or PID-readable/writable” magnetic cards (inconjunction with PID-initiated magnetic-stripe reader/writer functions)or other optional PID-initiated output target destination devices (notshown).

Some preferred embodiments of PIDs 100 permit integration of the PIDwith personal data assistants (commonly called PDAs), cellulartelephones, or other mobile electronic devices. Preferably this isimplemented by providing different adapters that permit coupling of PID100 with corresponding different mobile electronic devices. Sucharrangements would be especially beneficial in cases in whichsecurity-sensitive actions are to be performed using such mobileelectronic devices. The benefit of coupling any such mobile electronicdevice with a PID 100, is providing additional assurances that the userof that mobile electronic device has provided the proper user identitydata to the PID 100.

Preferred embodiments of PID 100 employ at least one biometric as theuser identity data. In these embodiments, a biometric input componentmust be used as part of the verification input component, either insteadof—or in addition to—the keypad 156 of FIG. 1. The biometric inputcomponent can vary widely, depending upon the biometric used. Examplebiometrics that might be used include: digit-prints (thumb- orfinger-prints), voice data, retinal data, iris data, and DNA data.Preferably, the biometric is a digit-print—and therefore—the biometricinput component is a component that can determine a user's digit-print.Various technologies are available for determining a user's digit-print.For instance, an optical scanner can be used to optically determine thedigit-print. More preferably, a capacitive sensor is used. Capacitivedigit sensors and their associated circuitry and software are availablecommercially, for instance the FPS 110 Sensor sold by Veridicom, theFINGERTIP Sensor, sold by Infineon, and the FINGERLOC AF-S1, sold byAuthentec Inc.

An example embodiment of a PID that uses a biometric as the useridentity data is shown in FIG. 3 as a BPID 200. Although the biometricinput component 190 could simply replace the keypad 156, FIG. 3illustrates some optional variations in the way the elements arearranged. For instance, in FIG. 3, a transceiver 125 is incorporated toboth receive and transmit signals to external devices. Rather than asingle processor 110 as in FIG. 1, multiple processors 110 are includedin FIG. 3. In particular, the arrangement indicated in FIG. 3 includes aprocessor 110 on the left that controls the flow of data to and from thetransceiver 125. The processor 110 in the middle controls the flow ofdata to the display 170. The processor 110 on the right controls theflow of data to and from all user input devices, including the userinput module 140 (which here includes only a joystick 144 with anactivation button 142) and the identity verification module 150. Infact, the processor 110 on the right doubles as the comparator 154(shown explicitly in FIG. 1) of the identity verification module 150.Similarly, the data storage medium 160 doubles as both the identity datamodule 152 (shown explicitly in FIG. 1 and which stores the biometrictemplates when one or more biometrics are used) and the repository forthe personal data and possibly for other data as well. Other embodimentsinclude various rearrangements and combinations of the elements of thePID and BPID into ways most suitable for the intended uses of thedevices.

Preferably in a BPID, security provisions are taken to ensure that onlya trusted party updates the biometric templates and their associatedverified data. Typically this party is a verification authority, thedetails of which will be discussed later herein. However, in someembodiments, the biometric data are updateable without the verificationauthority. For example, in some embodiments, a particular biometrictemplate is updated by the current biometric sample at either regular orirregular intervals. This procedure allows the current biometrictemplate to more accurately represent any minor changes in the biometricthat occur over time, e.g., as the individual ages. Updates that occurafter a specified number of accesses, wherein the specified number ofaccesses are chosen by the BPID itself in its software package andvaries depending upon an algorithm in the BPID, inhibit someone fromtrying to alter the template by repeatedly making very small changes tothe biometric. Not knowing when the biometric template updates itselfcomplicates any inappropriate alterations. In alternate embodiments,updates occur at irregular intervals of time, (rather than accesses);thereby further thwarting any attempts to inappropriately change thebiometric template. However, embodiments of the invention also includethose in which the biometric template is updated regularly and alsoembodiments in which the biometric template is updated on command of theuser. The level of confidence in the data associated with the biometrictemplate would likely be related to the manner in which the biometrictemplate were updateable.

Similarly, the error rate for false positives (accepting as a matchsamples from two different people) and false negatives (refusing toacknowledge as a match samples from the same person) in thedetermination of whether the biometric sample sufficiently matches thebiometric template is preferably set during manufacturing orregistration of the BPID. However, some embodiments allow for useradjustments of the error rates. Preferably such adjustments are onlyallowed within a range that provides acceptable confidence that thebiometric sample is the same as the person who provided the biometrictemplate. Preferred ranges for false positives are 1 in 1,000,000 or 1in 100,000. For some less secure applications, estimated reasonableranges for false positives range from 1 in 10,000 to 1 in 1000. Falsepositives that occur more frequently than 1 in 1000 are unlikely to beacceptable for most applications, although even higher rates of falsepositives might be acceptable in some very low-security embodiments. Onthe other hand, false negatives are largely an inconvenience. A lowfrequency of false negatives is desirable, but not required for mostembodiments.

To maximize its usefulness, a general PID (including a BPID) interactswith other devices. One such device is known as an information processorand is shown schematically in FIG. 4. The information processor 300includes: at least one processor 310, an information receiver 330 forreceiving information from a PID, a vendor connection 340, and afinancial intermediary connection 350. The processor 310 can be part ofa general-purpose computer that performs other functions as well asbeing part of the information processor 300. Preferably, the informationprocessor 300 also includes an information transmitter 320 fortransmitting information to a PID. Most preferably, the informationtransmitter 320 and the information receiver 330 are combined into aninformation transceiver (not shown).

Preferably, the information processor 300 serves as a bilaterallytrusted intermediary between parties, most often, between a payer and avendor. In some cases it serves as a “unit transaction processor” for asingle transaction only, while in other cases it serves as an “ongoingtransactions processor” for multiple transactions for that payer/vendorcombination. In some embodiments it serves as a “privacy processor” thatreceives pre-agreed payment transaction information from both the payerand the payee, and transfers only pre-agreed types of information toother parties.

Although not necessary, preferred embodiments of the informationprocessor also include a certification repository connection 360. Thevendor connection 340, the financial intermediary connection 350, andthe certification repository connection 360 are all preferably coupledto at least one processor 310 of the information processor 300.Preferably, the information processor 300 communicates wirelessly withthe PID. Wireless or wired connections to the vendor and the financialintermediary are both permitted.

In its most preferred form, the information processor 300 includeswireless communication with a PID through either an informationtransmitter 320 and an information receiver 330 or an informationtransceiver (not shown). The most preferred embodiment also includes acertification repository connection 360. In this most preferredembodiment, the information processor 300 is an embodiment of a wirelessverification processor (WVP) and it operates as follows.

In its most preferred embodiments the WVP is a front-end to an existingpayment system. The most preferred WVP contains the necessarysoftware/hardware functionality to: (1) communicate with one or morePIDs using a virtual wireless network, (2) obtain and verify the PIDdata stream with a public key located in a certification repositorydatabase, (3) interact with at least one financial intermediary toverify account data, and (4) interface with one or more additionalverification sources, networks, databases, as well as other WVPfacilities or similar products. A vendor connection is also required sothat product price and vendor account information is properly processed.

The WVP exchanges data wirelessly with a PID. Preferably, the two-waycommunication employs either infrared or radio frequency transmissions.Preferably, the transmitters and receivers in the WVP and the PID willbe designed with protocols (for example, Bluetooth) that correctpossible data collisions and provide reliable transmissions. In someembodiments, the WVP communicates with only one PID (i.e. when a PIDestablishes a connection, the WVP will ignore other signals and requestsuntil that particular connection and its associated transaction(s) iscompleted). In other embodiments, the WVP communicates with multiplePIDs.

In yet another series of embodiments PIDs interface with WVPs by meansof very short-range antenna footprint outputs from the PID. Thisapproach reduces the number of PID signals that are likely to besimultaneously received by the WVP, thereby avoiding signal congestionand/or WVP overload.

In the most preferred embodiments, the WVP has a connection with acertification repository database for verifying the PID transmission ofdata (i.e. to prove that the user of the PID is registered to use thePID). Preferably, the WVP has a high-speed connection to obtain a publickey from the certification repository database in which the PID isregistered. In addition, preferred embodiments of a WVP obtain andelectronically provide a financial intermediary with the necessaryaccount data for account verification. After the financial intermediaryreturns a response to the WVP, the WVP will return a message to the PID.

Other devices can also interact with a PID. A generic verificationprocessor is shown in FIG. 5. The verification processor 400 includes:at least one processor 410, a verification processor receiver 430 forreceiving information from a PID, a certification repository connection460, and an actuator connection 470. The processor 410 can be part of ageneral-purpose computer that performs other functions as well as beingpart of the verification processor 400. Preferably, the verificationprocessor 400 also includes a verification processor transmitter 420 fortransmitting information to a PID. Most preferably, the verificationprocessor transmitter 420 and the verification processor receiver 430are combined into a verification processor transceiver (not shown).

If the verification processor transmitter 420 and receiver 430 ortransceiver (not shown) communicate with a PID wirelessly, then thegeneric verification processor 400 shown in FIG. 5 is a WVP. The WVPdiscussed in the context of FIG. 4 employs the financial intermediaryconnection 350 as an actuator connection 470 (as illustrated in FIG. 5).In the context of this invention, the term “actuator” is used verybroadly and the financial intermediary is considered an actuator becauseit performs a user-initiated action, e.g., transferring money from theuser account to the vendor account (either account possibly beinglocated at another financial intermediary).

In combination with a PID, the general verification processor (or WVP ifwireless) can be used to unlock and/or open access-control mechanismsand locks associated with entryways (e.g., doors and windows), storagedevices (e.g., secure filing cabinets) and other systems that needprotected entry capabilities (e.g., data centers, databases). In suchcases the actuators perform (either directly or indirectly) theunlocking and/or opening function. Actuators can also be used to controlentertainment systems, telephones, automated teller machines andcomputers, and many other high-accountability systems that depend onsecurity to retain the faith of customers and vendors alike.

Before describing more applications of PIDs, verification processors,and systems comprised of these devices and variants thereof, preferredapproaches to registering a PID and its user are described.

Preferably, at manufacturing time or at a distribution outlet, each PIDwill be embedded with a control designation and private keys used forencryption. Upon purchase or ordering, the PID is preferably registeredto the user in the physical presence of a verification authority (VA).The VA may be a financial intermediary or some other trusted party thatcan perform identity verification. In preferred embodiments, the dataentered on a PID by a VA must be trusted by others. Any significant lackof trust of the data would largely negate the purpose of having a VA.Hence the VA has a self interest to ensure a certain level of accuracyof the data that it enters.

In many preferred embodiments in which PIDs are issued to employees forproviding controlled access to secure locations and/or equipment (e.g.,computers, cash registers, vaults, time card punch machines, etc.) theVA might be under the control of company officials (e.g., data centermanager, treasurer's office, paymaster office, etc.) while thecertification repository database might be maintained by the companysecurity office or the data center system administrator.

To increase trust and credibility for PID users and vendors alike, andin most preferred PID product distribution models, optimally, personaldocumentation that provides evidence of identity is required atregistration. Such trust and credibility evidence might include (but isnot limited to) presentation of a picture ID issued by a trusted party(such as a driver's license issued by a state and/or a passport issuedby a country), a “social security card” (or other evidence of a personalcontrol number), and/or other necessary and appropriate documentationsatisfactory to any or all of the owners of applications intended forreceiving PID access inputs by each PID user. Because so many uses andapplications are anticipated, the extent of registration credentialrequirements will vary widely between one individual and another, andwill depend on the number and type of security needed to satisfy allapplications each PID owner expects to access.

Preferably, in most PID registration scenarios and for mostapplications, the VA does not maintain any of the personal information,except possibly what is loaded into the certification repositorydatabase. However, for “private systems” (usually private, internalcompany, and custom vertical market applications) it is likely thatadditional strictures and/or control policies can be implemented, e.g.,in a company-wide system for personnel time card management, or inhighly secure applications serving necessarily secretive and closedcommunities (e.g., intelligence agencies, some military and governmentapplications, some private security companies). Additional stricturesmay also apply for some commercial in-house applications (in-storeinventory and control systems, banks, brokerages, high-technology labs,etc.).

At registration, the user initializes the device with user identitydata, which will become the stored identity data against which futurecomparisons are made to establish user identity. The VA will associatethe user identity data with the user's identity (name, personal controlnumber, and/or other form of identification) on the PID. Preferably, thePID is designed so that tampering with PID in an attempt to extract theuser identity data will result in the destruction of that data.Preferably, the VA does not maintain the user identity data, exceptpossibly for some private applications. Retained user identity data—atleast in most “conventional” application environments—are only availableonly on the PID, in accordance with the spirit of the invention. Again,other custom arrangements are possible to suit needs of the applicationowner and implementer (particularly in private and customvertical-market applications, which are usually privately owned).

For a non-biometric PID, the user identity data might consist of a passcode, which is a sequence of symbols, either entered on a keypad, spokeninto a microphone, or in some other way communicated to the PID. For thepurposes of the invention, the pass code can be as simple as amulti-digit PIN, or can be more complex to include a login/passwordcombination, a pass-phrase, or some other suitable security protocol.For a BPID, the user identity data is biometric. Some possiblebiometrics that might be used are: digit-prints (thumb or fingerprints),voice data, retinal data, iris data, and DNA data. The biometric dataprovided to the BPID in the presence of the VA becomes the biometrictemplate on the BPID. Preferably, multiple users can be enrolled to usea particular PID, unless forbidden by any intended application owner(usually only applicable to private systems).

In some embodiments, the VA also verifies additional personal datafields and associates this data with the user on the PID. Such personaldata fields might include financial account information, such as creditcard and/or bank account information. Other personal data fields, suchas address, phone number, marital status, salary, physicalcharacteristics, and medical information may also have values enteredand associated with the user. Depending upon the type of information andthe target application(s), different types of documentation might berequired by the VA. By providing documentation to the VA to substantiatethat the values of the personal data fields are valid, the enteredpersonal data field values are considered verified and their values maybe traded for discounts on purchases as described later. Preferably, thevalues of these personal data fields are maintained only on the PID.Preferably, the personal data fields that have been verified will beindicated as such on the PID. The certification repository databasepreferably includes only the PID identifier (preferably a unique controldesignation), the PID public key, and a list of user identifications(preferably name and/or other control number(s) pre-agreed by the PIDowner and the VA). However, in some embodiments, other information isalso included in the certification repository database. For instance, insome embodiments, the certification repository database indicateswhether the PID has access to particular financial accounts. Suchprivate information may be restricted so that it is not available to thegeneral public. Preferably, data verified by an in-person meeting with aVA representative is appropriately marked in the PID with a digitalcertificate or some other notarization from the VA.

Of course much data can also be entered into a PID without going to aVA. For instance, the user could enter credit card information. Thesoftware for entering the data would check to ensure that the useridentification (name and/or other secure control number(s) pre-agreed bythe PID owner and the VA) matched that of the credit card holder,thereby ensuring at least some level of confidence in the correspondencebetween the user and the cardholders. In some embodiments, anycard-providing web site will be capable of securely downloading accountdata and public keys into the PID. In general practice, the PID willdownload data from a financial intermediary or other website or downloadsource. The web site software would require the owner of the PID to fillin the necessary information. The web site software will also obtainfrom the PID its control designation and/or other data.

A PID can also be registered without physically going to a VA. Howevermost PID users are likely to register in person because in-personregistration decreases the chance of fraud and therefore increases thenumber of applications that are likely to be available to the user. Inparticular, certain high-security applications, including many vendorapplications, may require in-person registration as prerequisite toaccessing certain options. PID registration without an in-person meetingwith a VA representative would preferably require remote submission ofdocuments and a remote, but interactive session with a VA representativeor VA-run software. Most preferably, the interactive session wouldinclude real-time video so that the VA representative or the VA-runsoftware could compare the image of the individual seeking to registerthe PID with a picture ID. This would enable the VA to come to at leasta tentative conclusion that the individual matches the picture ID.Real-time video is especially preferred in the case of a BPID, where theuser identity data is biometric. The real-time video, although nottamper-proof, provides the VA representative or VA-run software anopportunity to confirm that an individual that resembles the individualon the picture ID is providing the biometric sample that will become thebiometric template against which future biometric samples will becompared. Preferably, such remote verification would be appropriatelyindicated with information stored on the PID. Because of the greaterlikelihood of fraud with remote registration, some vendors and otherapplications that desire high security may limit the user options whenvarious aspects of PID registration are performed remotely.

Future advances in personal identification techniques may provide othermeans in which remote verification of identity can be performed.Alternatively, some application providers may be willing to sustainincreased risk in their transactions (particularly in low- orno-security applications) hence remote verification, with or withoutreal-time video may not be an important issue for them.

Systems employing PIDs can be used in many applications. For instance,FIG. 6 shows a verification system 500 that includes a PID 100, averification processor 400, and an actuator 510. In such a system, thePID 100 is only required to be a portable device that authenticates thata user of the device is privileged to use the device and is privilegedto request that the user-initiated action be taken. After authenticatingthe user privileges, the PID transmits signals that encode: anidentification, and an instruction that the user-initiated action betaken. Details of the structure of a PID 100 described above inconnection with FIGS. 1 and 2 are not required in such a system.Similarly, a verification processor 400 is a device that receivessignals from the PID and verifies that the identification sent by thePID 100 is associated with a PID that is authorized to request that theuser-initiated action be taken. Preferably, the identification is thePID control designation. Alternatively, in some embodiments theidentification identifies the user of the PID rather than the PIDitself. The user identity can be a name, a personal control number, orsome other data that identifies the user. After verification, theverification processor 400 signals the actuator 510 to perform theuser-initiated action.

The actuator 510 is broadly interpreted to include any means used toaccomplish the user-initiated action. For example, in embodimentsinvolving the opening or unlocking of access-ways such as doors andwindows, the actuator 510 receives signals from the verificationprocessor 400 and performs the mechanical task of opening or unlockingthe access-way, as desired. In other embodiments the actuator 510processes electrical signals. For instance, in a verification systemthat interacts with a graphical user interface, the user-initiatedaction typically involves the movement of a cursor or the selection ofan icon. The actuator 510 is the device responsible for the movement ofthe cursor or the selection of the icon. In other embodiments ofverification systems, the actuator 510 manipulates data. For instance,in a verification system used for conducting a financial transaction,the actuator 510 could be a financial intermediary that is responsiblefor debiting and/or crediting accounts.

Preferably, in such a verification system, the PID is a BPID andtherefore the device authenticates that the user of the device isprivileged to use the device by determining that a biometric samplecollected from the user sufficiently matches a biometric template thatstored locally on the BPID.

Preferably, the PID and the verification processor in the verificationsystem communicate wirelessly. Preferably, their communication isencrypted. Most preferably the encryption is performed using a publickey/private key algorithm. In such a case, preferably the private key isstored on the PID and the corresponding public key is maintained incertification repository database.

The certification repository database is preferably located on an opennetwork, although in some embodiments, the certification repositorydatabase is either local to the verification processor, or located on aclosed network available to the verification processor. Preferably thecertification repository database links the public key with theidentification sent to the verification processor by the PID. The samepublic key may be available to several identifications. For instance,the identity of multiple users registered to use a single PID might allbe linked to the same public key. Also, the certification repositorydatabase might associate both PID control designations and useridentities to the same public key. In this way, the proper public keycould be accessed with either the user identity or the PID controldesignation.

The verification system described above can be used in a variety ofapplications. For example, various embodiments expedite user requeststhat seek access to, and/or control of, enterprise resources andenterprise transactions processing facilities. In such cases, theactuator is the resource to which access is desired, and uponverification that the user is privileged to access the resource, useraccess is permitted. A typical enterprise resource managementenvironment is a local area network (LAN) in which users are mobile androve. A roving user may have privileges to access and control only a fewcomputers (e.g., in workgroups similar to his or her own desktop), orthe roving user may have more extensive privileges.

Other applications are exemplified by proprietary content browsing(including pay television, pay audio, pay entertainment, royalty-basedofferings such as ASCAP or other proprietary music or offerings). Inaddition, the verification system may be used in conjunction withautomated teller machines, pay telephones, information kiosks, vendingmachines, and simulated inventories. In many of these applications, theuser-initiated action may be initiated by the movement of a cursor orthe selection of an icon in a graphical user interface.

Further applications involve circumstances in which continuous (orrepeated) authentication is required, such as testing (includingcomputer-based programmed instruction, university or scholastictesting), voting, polling, and other applications where continuous orrepeated authentication and security are required or helpful to serveall concerned.

A specific example of how the invention might work in the context of afinancial transaction is discussed below. In this example, the PID is aBPID, which communicates wirelessly with the verification processor,which is a WVP. A connection to a vendor is also included in thisexample.

The user selects items for purchase and places them into a shoppingcart, (which may be an electronic shopping cart). The vendor sums thepurchase prices and any other appropriate charges (e.g., shipping,handling, tax, etc.) to determine a purchase price. The purchase priceis communicated to the user either directly, or through a WVP to whichthe vendor is connected. For an online or Internet purchase, the WVPmight be connected to the user's computer and only indirectly connectedto the vendor. For a conventional store, the WVP is preferably connectedto the cash register or similar equipment. The user activates his/herBPID and indicates a credit card account that the user wishes to use tomake the payment. The BPID transmits an encrypted data stream of creditcard account data (including the financial intermediary address),date/time stamp, and BPID control designation, and etc. to the WVP. Thedata stream is encrypted with a BPID private key that was assigned tothe BPID either at manufacturing time, or upon registration. Theencrypted date/time stamp keeps a “dynamic” data stream (i.e. the samedata stream can never be duplicated). The WVP receives the encrypteddata stream and decrypts the data with a public key, which is located ina certification repository database, which in this example is a databasethat contains public keys for each PID. After the WVP verifies that thedata came from the appropriate BPID user, the WVP provides the financialintermediary with the necessary account data. The financial intermediaryis provided these data in any suitable manner, but most preferably thesedata are packaged to match the presently used data streams for makingfinancial payments. The financial intermediary is considered theactuator in this case. The financial intermediary takes the implieduser-initiated action of checking the data and either approving ordisapproving the requested financial transaction, depending upon thestatus of the user's account. Then an approval/disapproval data streamis returned to the WVP, which further relays the approval/disapprovalmessage appropriately encrypted to the BPID and to the vendor. The userthen indicates with the BPID go forward with the purchase. Theappropriately encrypted message is sent to the WVP, which forwards themessage to the vendor (which is the actuator for this portion of theprocess). The vendor then completes the sale as usual. In someembodiments, a record of the transaction is maintained on the BPID. Thisrecord can later be downloaded to the user's choice of personalaccounting system.

In applications involving financial transactions, multiple layers ofencryption are preferred. An example of an embedded encryption procedureis described below. Numerous alternative procedures could also beemployed.

In a preferred procedure, each account included on the PID will beassociated with a public key provided by the financial intermediary thatissued the account, or provided indirectly via a public key repository.When the user of a PID selects an account to use in a specific financialtransaction, the PID appends date and time information to the accountinformation and encrypts the data stream with the public key associatedwith the selected account. The use of date and time information forcesthe encrypted bit pattern to be different every time the PID is used tomake a financial transaction. The differing bit patterns guarantees thata signal intercepted by a third party cannot be simply repeated to gainaccess to the account (a.k.a. “replay attack”).

After encrypting the date, time, and account information with the publickey of the account, the PID control designation and the financialintermediary address (or some other indicator of the financialintermediary) are appended and encrypted with the private key associatedwith the PID. The PID control designation is then appended to theresultant data stream.

The embedded encrypting provides the opportunity for increased securityand privacy. With the above encrypting procedure, the device thatreceives the data from the PID would first consult a table of publickeys to find the public key associated with the PID. This public keywould be used to decrypt the information encrypted with the PID privatekey. Decrypting this information gives the receiving device access to asecond copy of the PID control designation. The receiving device shouldconfirm that the two copies of the PID control designation match. Atthis point, the receiving device also has access to the financialintermediary address and can route the remaining information to thefinancial intermediary. Because this information was encrypted with thepublic key associated with the account in the indicated financialintermediary, decrypting the information requires the correspondingprivate key, which presumably is maintained by the financialintermediary.

Numerous variations to the encryption strategy can be used in variousembodiments. In particular, hybrid schemes that exploit both asymmetricand symmetric algorithms may provide the convenience and security ofasymmetric algorithms with the inherent speed advantage of symmetricalgorithms. In a hybrid scheme, an asymmetric encryption algorithm isused to encrypt a key to a symmetric algorithm, which is used to encryptthe bulk of the message.

Any of the described encryption schemes may be used in whole or in partin combination with various aspects of the invention.

In addition to the general verification system described previously, theinvention includes related systems specifically designed for a payer toconvey a payment to a payee. A schematic of an embodiment of such asystem is illustrated in FIG. 7. The system includes a PID 100, aninformation processor 300, and a financial intermediary component 600.In this system, the PID 100 authenticates that a user of the PID 100 isprivileged to use the PID 100 and is privileged to request that apayment be charged against a payer account. The PID 100 then transmitssignals to an information processor 300. These signals include the payeraccount data and the payer financial intermediary address. Theinformation processor 300 receives signals from both the PID 100 andfrom the payee 610. The signals from the payee 610 include the payeeaccount data and the payment amount. The information processor 300 thenforms a payee payment packet that includes the payer account data, thepayee account data, and the payment amount, and sends the payee paymentpacket to the payer financial intermediary address The financialintermediary component 600 receives the payee payment packet andtransfers money from the payer account at the payer financialintermediary to the payee account at the payee financial intermediary.In some embodiments, the payee 610 acts as his/her own financialintermediary, in which case, the transfer of funds is made directly tothe payee 610. The payer can also act as his/her own financialintermediary, but such an arrangement would not change the flow ofinformation.

Note that the user of the PID 100 does not need to be the payer, butmust have privileges to use the PID 100 and have privileges to requestthat a payment be charged against the payer account. For example, theuser of the PID 100 might be a child of the payer. The child might havelimited privileges to use the PID 100. For instance, some accounts mightbe off limits or might have per transaction or per month limits imposed.How such limits are imposed and changed is specific to various PIDembodiments. Preferably, all such information is local to the PID 100.

In preferred embodiments the authentication that the user of the PID 100is privileged is done by determining that a biometric sample collectedfrom the user sufficiently matches a biometric template stored on thePID 100 (which in such a case is a BPID) and associated with theselected payer account data.

In preferred embodiments, the communication between the PID 100 and theinformation processor 300 is wireless.

Preferably, the information processor 300 verifies that the payeraccount data is valid, preferably by communicating with the payerfinancial intermediary.

Preferred embodiments of the system further include a certificationrepository database 620. In these preferred embodiments thecertification repository database 620 includes PID control designationsand registered users. The PID 100 transmits the PID control designationto the information processor 300, which checks the certificationrepository database 620 to verify that the PID control designationcorresponds to a PID 100 that is registered for use by the payer. In atypical embodiment, the payer identity is registered in thecertification repository database 620 and is associated with the PIDcontrol designation. Preferably, the verification by the informationprocessor 300 occurs with the use of a public key that is located in thecertification repository database 620.

In an example verification process, the user is authenticated to the PID100, either through a biometric, a pass code, or some other means. ThePID 100 then obtains a public key from the information processor 300.The PID 100 encrypts its PID control designation using the public key ofthe information processor 300. This information is transmitted to theinformation processor 300, which decrypts the information using itsprivate key. The information processor 300 then consults thecertification repository database 620, where the public key of the PID100 that corresponds to the PID control designation is obtained. Achallenge message is encrypted with the public key of the PID 100 andtransmitted to the PID 100. The challenge message is decrypted by thePID 100, then re-encrypted using the public key of the informationprocessor 300, then transmitted back to information processor 300. Theinformation processor 300 decrypts the challenge message using itsprivate key. If the challenge message matches the challenge message thatit originally sent, then the PID 100 is verified as having the properprivate key that corresponds with the PID control designation originallysent to the information processor. Variations to such public key/privatekey verifications known to those skilled in the art are included withinthe meaning of verifications using public keys. Verification that a useridentity is associated with a particular PID control designation in thecertification repository database 620 is preferably done simultaneouslywith the previously described checks. However, various embodiments mayverify that the user is registered to use the PID 100 either before orafter the PID control designation is checked.

A related system involves a simulated inventory system, as shownschematically in FIG. 8. As used here, a simulated inventory is visualrepresentation of a catalog, index, directory, or other content.Referring to FIG. 8, a simulated inventory system 650 comprises asimulated inventory display 670, a simulated inventory controller 660that controls the interaction of at least one cursor with at least oneicon on the simulated inventory display 670, and a PID 100.

Preferably the simulated inventory takes the form of either atwo-dimensional or three-dimensional graphical user interface that isdisplayed on the simulated inventory display 670. Three-dimensionalgraphical user interfaces can be produced with perspective on a surface(either flat or curved) or (in advanced, premium applications) throughthe use of holographic images. The use of the phrase “on the simulatedinventory display 670” is intended to include both projections onto asurface and holographic projections, in which the preposition “in” wouldbe more appropriate.

The term “cursor” is used here to mean an easily recognizable indicatorof the user's position in the simulated inventory. In this application,the cursor, (or an avatar in embodiments in which an avatar is used asthe cursor), is displayed on the simulated inventory display 670,allowing the PID user to manipulate product images and icons.

In simulated inventory systems 650, the PID 100 is a portable devicethat authenticates that a user of the device is privileged to use thedevice. In addition, the PID 100 in these systems includes some of theelements shown in FIGS. 1 and 3 and previously discussed. In particular,in simulated inventory systems, the PID includes a transmitter 120, auser input module 140 that receives inputs from the user, and aprocessor 110 that receives the inputs and provides correspondingsignals to the transmitter 120. The signals sent by the transmitter 120are received and processed by the simulated inventory controller 660,which then updates the image on the simulated inventory display 670.

A positional sensor 149 (shown in FIG. 1) is particularly useful formanipulating a cursor through a three-dimensional simulated inventory.The orientation of the PID 100 can then be used as an additional userinput to guide movement of the cursor.

Unless required by the simulated inventory controller 660, the realidentity of entity controlling any particular cursor need not berevealed.

The simulated inventory display 670 is preferably individualized foreach PID 100 that is part of the system. These embodiments require atleast one simulated inventory display 670 for each PID 100. Alternateembodiments employ fewer simulated inventory displays 670 and includeindividualized cursors for each PID. Such systems might be used in ahybrid physical-simulated shopping environment. Customers wouldphysically gather at one or more locations that include a simulatedinventory display 670. At these locations, the customers could enter thesimulated inventory system 650 and search for and perhaps purchase thedesired goods and/or services. The goods and/or services could then beimmediately retrieved, rather than requiring shipping.

The apparatuses and systems described above facilitate new methods forconducting transactions. However, unless the methods described belowspecifically state that one or more embodiments of the above-describedapparatuses and/or systems are necessary, the methods are not requiredto include the above-described apparatuses and/or systems.

One new method is a method for discounting a deliverable that has aprice. In an embodiment of the invention, a party receives from thecustomer a value for at least one prescribed personal data field. Thevalue of the at least one prescribed personal data field is certified ascorresponding to the customer. Finally, the price of the deliverable isreduced by a prescribed discount. The prescribed discount is independentof the value of the prescribed personal data field. The discount dependsonly on the fact that the customer has provided a value for theprescribed data field.

Preferably, a PID is used for certifying that the personal data fieldcorresponds to the customer. Most preferably, documentation is providedto the VA during PID registration that indicates the values of variouspersonal data fields. The VA has software and hardware that associatesthese values of the personal data fields with the appropriate registrantof the PID. When a PID authenticates the identity of a customer as aparticular registrant of the PID, the values of the personal data fieldsassociated with that registrant are considered to be certified. Althoughcertification through the use of a PID is preferred, any other suitablemeans may be used to certify that the personal data field corresponds tothe customer.

In some embodiments, the certifying step for this method includescollecting a biometric sample from the customer and authenticating thatthe collected biometric sample sufficiently matches a biometric templateassociated with a verified set of personal data field values. Althoughnot necessary, these embodiments are preferably facilitated with the useof BPID. In the case of a BPID, the original biometric template isprovided to the BPID in the presence of the VA. Thereupon the VAassociates the registrant identity and any documented personal datafield values with the biometric template. The particular biometrictemplate used is not critical. Various embodiments employ digit-prints,handprints (evaluation of hand geometry), voice data, retinal data, irisdata, and DNA data. In preferred embodiments, security provisions in theBPID prevent the biometric template from being altered except throughthe hardware and software provided to the VA. However, other embodimentsallow the biometric template to be updateable, either at intervalschosen by the BPID hardware and/or software, or by the user of the BPID.

Non-biometric methods for certifying that the values of personal datafields correspond to the customer are also possible. For instance, insome embodiments a handwriting sample is collected from the customer. Ifthe collected handwriting sample sufficiently matches a storedhandwriting sample associated with a verified set of personal data fieldvalues, then the values of the personal data fields are certified. If aPID is used, a similar registration process to that used with thebiometric template can be used to ensure that the personal data fieldvalues are verified and that the stored handwriting sample correspondsto them. However, in this case, rather than providing a biometrictemplate, a handwriting sample is provided. Some embodiments of PIDs areequipped with handwriting input and analysis hardware and software toautomatically authenticate a user's handwriting. Similarly, in variousembodiments, a pass code is used to authenticate the identity of a user.Although the use of a PID is preferred, its use is not required.

To arrive at the appropriate discount for the deliverable, someembodiments of the method prescribe a negotiation. The negotiation maybe between the customer and the vendor, the customer and themanufacturer, or the customer and some other party. The negotiation isdefined as a communication or set of communications that seek todetermine an acceptable discount that will be granted in exchange forvalues of selected personal data fields. As an example, a vendor mightdesire the customer's name, address, and phone number in exchange forthe grant of a discount of X. The customer might be willing to providename and address information, but not the phone number. The negotiationwill attempt to find some set of personal data fields that are worthsome discount to both the vendor and the customer. In the example givenabove, the vendor might agree to accept the customer's name, address,and email address in exchange for a discount Y that is somewhat lessthan X.

In preferred embodiments, the determination of which prescribed personaldata fields the customer will provide with values and the prescribeddiscount that the customer will receive, are the result of anoptimization algorithm based upon constraints and cost functions thatare specified by the customer and the discounter. Constraints areconditions that are not to be violated. For instance, in the priorexample the customer was willing to provide a value for the customer'semail address, but not for the customer's telephone number. The refusalof the customer to provide a telephone number is a constraint. Costfunctions are mathematical descriptions of penalties associated with anon-optimal result.

In simple examples, cost functions are just numerical values that areassociated with various possible outcomes. For example, in the priorexample, the vendor optimally desired the customer's name, address, andtelephone number. A zero value of the vendor's cost function would beassociated with this outcome. However, the vendor was willing to acceptthe customer's email address in place of the customer's telephone numberif the discount was modified from X to a smaller value of Y. In spite ofproviding a smaller discount, the vendor is not as pleased with thisoutcome as he/she would have been had the customer agreed to provide thecustomer's telephone number. Hence the cost function is nonzero, in thisexample, let us assign the vendor's cost function to be 1 to thissituation. In this example, assume that the vendor would also haveaccepted the customers name and address in return for a much smallerdiscount, Z. This outcome was less optimal to the vendor and thevendor's cost function was 3. The customer will also have a set of costfunctions. For instance, a value of 1 might be assigned to the trade ofthe customer's name and address for a discount of Z. A value of 2 mightbe assigned to the trade of the customer's name, address, and emailaddress in exchange for a discount of Y. The customer constraintprohibits any consideration of releasing the customer's telephonenumber. An optimization algorithm would determine the least costlyoutcome consistent with the constraints. In this case, the sum of thecustomer's cost function and the vendor's cost function is 4 if thecustomer provides only name and address values in exchange for adiscount of Z. On the other hand, the sum of the cost functions is 3 ifthe customer provides a name, address, and email address in exchange fora discount of Y. The latter option minimizes the cost functions whilestill complying with the constraints; hence it is the optimal outcome ofthis example.

In the above example, integer values were assigned to the individualoutcomes. In general, the value of the cost functions for differentoutcomes will be non-integers. Also in the above example the customer'scost function was specified at the precise discounts specified by thevendor's cost function. In general, interpolation will be required todetermine the appropriate values of the cost function. For instance,both the vendor and the customer might specify cost function values fora range of discounts for the same prescribed personal data fields.Discounts outside of the specified range could optionally have theircost function either extrapolated or set to some preset value.

Although the method requires that the value of at least one prescribedpersonal data field is certified as corresponding to the customer, notall personal data fields used in the optimization scheme need to becertified. Typically, personal data fields that relate to personalpreferences and/or hobbies are difficult to document and therefore wouldlikely be non-certified. In addition, some individuals may not wish togo to the trouble of having a VA certify a new address or phone number,hence their entries in those personal data fields would not becertified. Non-certified personal data fields are likely to be lessvaluable to the discounter, but may nonetheless have significant value.The importance of whether a particular personal data field is certifiedor not is specified by assigning a separate cost function and/orseparate discount to either case.

Whether the value of a particular personal data field is restricted touse by the discounter or can be sold or transferred to another entityalso enters into the optimization process. Different discounts and/orcost functions can be assigned to personal data fields depending uponwhether or not the information is restricted to the discounter. Inpreferred embodiments, all transferred information is restricted to thediscounter, but such a restriction is not required.

When a PID is used to facilitate this method of discounting, preferablythe cost functions are set during enrollment of the PID. A set ofdefault cost functions are optionally made available for those PID usersnot wishing become involved in the details of setting their own. In mostembodiments, the cost functions may be changed or set at some later timewithout the involvement of a VA.

A benefit function can be interpreted as an inverse cost function. Thebenefit function describes how satisfied the entity is with anyappropriate outcome. An optimization algorithm would seek to maximizebenefit functions. A preferred embodiment of the method employingbenefit functions is illustrated in the schematic of FIG. 9 and isdescribed below.

In these preferred embodiments, the customer specifies a customerbenefit function (CBF) 712 that relates how satisfied the customer wouldbe to receive a specified discount in return for the value of aspecified personal data field. The customer also specifies any customernon-negotiable constraints 714 on individual personal data fields orcombinations of personal data fields. For instance, the customer mightbe willing to provide either a telephone number or an address, but notboth.

Similarly, the discounter specifies a discounter benefit function (DBF)722 that relates how satisfied the discounter would be to provide aspecified discount in return for the value of a specified personal datafield. The discounter also specifies any discounter non-negotiableconstraints 724 on individual personal data fields or combinations ofpersonal data fields. For instance, the discounter might insist onreceiving both a telephone number and an address, In these embodiments,the customer also needs to specify a customer benefit functionnormalization value (CBFNV) 716. The CBFNV normalizes the customerbenefit function. In preferred embodiments, the CBFNV is related to someminimum nonzero value of the customer benefit function that the customerconsiders satisfactory. Although not required, in some embodiments, thisminimum value of the customer benefit function is explicitly imposed asa non-negotiable constraint.

Similarly, the discounter specifies a discounter benefit functionnormalization value (DBFNV) 726. In preferred embodiments, the DBFNV isrelated to some minimum nonzero value of the discounter benefit functionthat the discounter considers satisfactory. Although not required, insome embodiments, this minimum value of the discounter benefit functionis explicitly imposed as a non-negotiable constraint.

In preferred embodiments the CBFNV and the DBFNV correspond to minimumvalues of their respective benefit functions that are satisfactory tothe customer and the discounter respectively. In such embodiments, theratios CBF/CBFNV and DBF/DBFNV can be directly compared because bothrepresent a level of satisfaction that is normalized with a minimumlevel of satisfaction acceptable to the respective parties. In the mostpreferred embodiments, the minimum acceptable values are imposed asnon-negotiable constraints. By imposing the minimum acceptable values asnon-negotiable constraints, the ability of both the customer and thediscounter to manipulate numbers in their favor by choosing anartificially low customer or discounter benefit function normalizationvalue is reduced. In such embodiments, setting an artificially low valuemay result in actually obtaining an outcome that corresponds to thatartificially low benefit function value. Imposing a greater minimumvalue eliminates the possibility of considering outcomes with lowervalues of the respective benefit functions.

If any of the non-negotiable constraints are not met, no discount isprovided and the customer is not obligated to provide values for anypersonal data fields. Similarly, if either the customer benefit functionor the discounter benefit function is less than the specified minimumvalue acceptable, no discount is provided and the customer is notobligated to provide values for any personal data fields.

Although benefit functions may be established in any way acceptable toboth the customer and the discounter, preferred embodiments aredescribed below.

In the preferred embodiments, to establish benefit functions, benefitvalues are chosen for various outcomes. Outcomes not explicitlyspecified are constructed from the specified benefit values.

As an example, consider the benefit values assigned by a customer inTable 1. Four personal data fields, labeled 1-4 are used. Discounts maybe specified as either absolute amounts or percent of purchase price. Inthis example, the preferred practice of specifying the discounts interms of percent of the purchase price is used. The table specifies thecustomer benefit value assigned to outcomes in which discounts rangefrom 1% to 4%. The fifth and sixth columns provide benefit assignmentsfor combinations of personal data fields. In preferred embodiments, whencombination fields are provided, the combination field including thegreatest number of fields takes precedence over sums of individualfields and/or combination fields with fewer fields.

The customer benefit function is the sum of the benefit values for anyparticular outcome. Interpolation is used to establish the customerbenefit for cases between those specified. Depending upon customerpreference, extrapolation, or a default value is used for cases out ofthe range of the table. Because different ways of arranging acombination of fields to achieve a specified discount exist, a procedurefor choosing which combination to use must be established. In preferredembodiments, the combination that gives the maximum sum of the customerbenefit values is chosen, and the sum is the customer benefit function.However, other embodiments choose the combination that produces theminimum sum. Still other embodiments choose an average of the possiblesums to be the customer benefit function.

To better understand how the table is used in practice, consider apossible outcome in which the values of personal data fields 1 and 2 aretraded for a discount of 5%. Because the combination of fields 1 and 2is not separately provided, the customer benefit function is determinedby evaluating the possible ways in which fields 1 and 2 can be combinedfor a 5% discount. In this example, the maximum of the sum of thebenefit values of the different combinations in which fields 1 and 2 canbe combined will be chosen for determining the customer benefitfunction. A 1% discount for field 1 (customer benefit value of 1) and a4% discount for field 2 (customer benefit value of 4) result in a totalof a 5% discount and give a sum of 5 (1+4). We can also consider a 2%discount for field 1 (customer benefit value of 1) and a 3% discount forfield 2 (customer benefit value of 3), resulting in a sum of 4. Because4 is less than 5, the maximum sum is still 5. All the other combinationsalso give sums of 4, therefore the maximum remains 5 and the customerbenefit function is 5.

Now consider a case in case in which fields 1 and 3 are desired for atotal discount of 3%. Because the combination of fields 1 and 3 isspecified in the table, the customer benefit function is simply readfrom the table as 2.

Finally consider a case in which fields 1, 3 and 4 are desired inexchange for a discount of 5%. Because the combination field 1 and 3 isspecified, the customer benefit function is evaluated by consideringdifferent ways in which the 1 and 3 column can be combined with thefield 4 column to provide a total discount of 5%. By searching for themaximum, a customer benefit function of 4 is found. Although thisparticular table does not include a column for the combination field 1and 4, if such a column was provided, the determination of the customerbenefit would also need to consider ways in which the combination field1 and 4 could be combined with field 3. In this example, the maximumover all the combinations becomes the customer benefit function.However, if fields 1-4 were desired for 5% discount, only combinationsof the combined 1, 2, and 3 fields (rightmost column) with field 2 wouldbe considered because precedence is given to combination fields thatinclude the most fields.

In practice, the customer may choose default customer benefit functionvalues.

Clearly discounter benefit functions can be determined similarly using atable specified by the discounter.

The optimization algorithm may bias the optimization with the use of acustomer biasing factor (CB) and a discounter biasing factor (DB).Preferably CB=DB=1, which is equivalent to not using either biasingfactor. If CB>DB, then the optimization algorithm favors the customer.If CB<DB, then the optimization algorithm favors the discounter.

The optimization algorithm determines which personal data fields areprescribed and what the prescribed discount is by maximizing the sum ofthe product of the customer biasing factor with the ratio of thecustomer benefit function to the customer benefit function normalizationvalue and the product of the discounter biasing factor with the ratio ofthe discounter benefit function to discounter benefit functionnormalization value, subject to any customer non-negotiable constraints,and any discounter non-negotiable constraints.

As shown with reference numeral 720 in FIG. 9, mathematically, theoptimization algorithm maximizes:

CB(CBF/CBFNV)+DB(DBF/DBFNV)

without violating any of the non-negotiable constraints imposed by theeither the customer or the discounter, respectively. If no outcomesatisfies the constraints, no discount is provided and the customer doesnot need to provide values for personal data fields.

TABLE 1 Field Discount 1 2 3 4 1 & 3 1, 2, & 3 1% 1 1 1 1 0 0 2% 1 2 1 21 1 3% 2 3 1 2 2 4% 3 4 2 3 3 2

The entire process circumscribed by the outer box 710 of FIG. 9 providesa preferred method of determining what are the prescribed personal datafields and what prescribed discount will be provided in return for thevalues of those fields. After the prescribed personal data fields aredetermined, the discounter receives values for those prescribed personaldata fields 730. The value of a personal data field is certified ascorresponding to the customer 740 and the price of the deliverable isreduced by the prescribed discount 750.

Other embodiments of the invention include methods by which a payerconveys a payment to a payee. In various embodiments of such methodspayer payment information includes: a payer financial intermediaryaddress corresponding to an appropriate payer financial intermediary,payer account data that specifies a payer account from which payment isto be made, and a PID control designation. In this context the PIDcontrol designation is an identifying sequence of data given to a PIDand in this context a PID is a portable device that authenticates that auser of the device is privileged to make a payment from the payeraccount specified in the payer account data. Other aspects of PIDsdescribed earlier are not necessary in this context.

As shown in FIG. 10, various embodiments of these methods include thesteps of: receiving payer payment information from the payer 810,confirming that the PID control designation corresponds to the PID thathas been registered in the name of the payer and is privileged to accessthe payer account 820, forming a payee payment packet 830, sending thepayee payment packet to the payer financial intermediary address 840,and accepting payment from the payer financial intermediary 850. In thiscontext, the payee payment packet includes the payer account data, payeeaccount data, and a payment amount. Although not required in allembodiments, the steps of FIG. 10 are performable solely by the payee.

In various embodiments, the payee takes the role of both the payee andthe payee financial intermediary.

In some embodiments the step of sending the payee payment packet to thepayer financial intermediary address 840 is performed via the payeefinancial intermediary, as indicated by the dashed lines leading to andfrom step 835. These embodiments follow more closely current credit-cardpractice in which the payee (typically a vendor) sends data to the payeefinancial intermediary and the payee financial intermediary forwardsinformation to the payer financial intermediary.

Various embodiments of this method for conveying a payment include thestep of debiting the payer account by the payment amount plus a payersurcharge. The payer surcharge may be a sum of surcharges assessed bymultiple entities. In preferred embodiments the payer surcharge is zero.In preferred embodiments, the step of accepting payment from the payerfinancial intermediary occurs when the payee account is credited by thepayment amount minus a payee surcharge. Although the payee surcharge maybe zero, it is nonzero in most preferred embodiments. The payeesurcharge may be the sum of surcharges assessed by multiple entities. Inparticular, the multiple entities that assess surcharges in preferredembodiments include the payee financial intermediary, the payerfinancial intermediary, and a credit-card company. In other embodimentsdifferent entities may assess surcharges.

In preferred embodiments, the step of confirming that the PID controldesignation corresponds to the PID registered in the name of the payerand is privileged to access the payer account 820 is performed byconsulting a certification repository database. In these embodiments thecertification repository database includes information as to whether ornot the PID is allowed to access particular accounts. However, thisinformation may be restricted, for instance to particular vendors orfinancial intermediaries. In some embodiments, the payer financialintermediary maintains the certification repository database. In someembodiments different databases are consulted for confirming that thePID has been registered to the payer and that the payer is privileged toaccess the payer account.

In preferred embodiments, the payer account data is encrypted.Encryption reduces the chance that confidential payer account data canbe used by an unauthorized or an unintended party. In many preferredembodiments most (if not all) data transfers are encrypted, not justthose containing account data. Encrypting the payer account data, allowsthe payer account data to be handled by the payee without providing thepayee with access to the payer account data. Preventing the payee fromhaving access to the payer account data is important in manyembodiments.

The most preferred embodiments employ a BPID (biometric personalidentifying device) rather than a non-biometric PID. In theseembodiments, the PID authenticates that the user of the device isprivileged to make a payment from the payer account by determining thata biometric sample collected from the user sufficiently matches abiometric template associated with the payer account data, and whereinthe biometric template is stored locally on the PID. To reduce thepossibility of fraud, preferably the biometric sample collected from theuser is collected within a preset time period, prior to payer paymentinformation reception by any payee. Without such a “time-out” period,unauthorized transactions could be made by others after the BPID hadauthenticated a particular user.

The particular biometric that is used to authenticate the user differswith different embodiments. For instance, in various embodiments thebiometric sample can be one or more biometrics, including a digit-print,a handprint, voice data, retinal data, or DNA data. Other embodimentsemploy combinations of various biometrics.

Preferably, a VA (verification authority) had associated the payeraccount data with the biometric template on the PID. This wouldtypically be done at registration or at some later time. Because the VAhas a self interest in providing trusted service, the VA preferablyrequires documentation that the payer account data should be accessibleby the provider of the biometric template before the VA associates thepayer account data with the biometric template on the PID. The use of aVA adds confidence to the veracity of the association between thebiometric template and the payer account data. In preferred embodiments,security provisions in the PID allow only the VA can change theassociation of data on the PID. In other words, any data associated witha particular biometric template, is only changeable by a VA. In someembodiments, the biometric template is updateable, either by the VA orthrough some other trusted security administrator or systemadministrator means.

In various embodiments of the method, an additional step is includedthat confirms that the payer account has sufficient solvency to bedebited by the payment amount. Preferably, this confirmation isperformed by the payer financial intermediary.

A similar set of embodiments by which a payer conveys a payment to apayee, includes the steps of: receiving payer payment information from apayer 810, forming a payee payment packet 830, sending the payee paymentpacket to the payer financial intermediary address 840, and acceptingpayment from the payer financial intermediary 850. In this set ofembodiments, the payee payment packet includes the PID controldesignation, the payer account data, the payee account data, and apayment amount. Because the PID control designation is included in thepayee payment packet, the step of confirming that the PID controldesignation corresponds to a PID that has been registered in the name ofthe payer, and is privileged to access the payer account 820, can beaccomplished by some party that receives the payee payment packet.Additional embodiments corresponding to those described for the priormethod by which a payer conveys a payment to a payee are applicablehere.

FIG. 11 illustrates another related set of embodiments in which a payerconveys a payment to a payee. This set of embodiments includes the stepsof receiving a payee payment packet 910 and debiting the payer accountby the payment amount plus a payer surcharge 920. In this set ofembodiments the payee payment packet includes payee account data, apayment amount, payer account data, and a PID control designation. Inthe context of these embodiments, the PID control designation is anidentifying sequence of data given to a PID and a PID is a portabledevice that authenticates that a user of the device is privileged tomake a payment from the payer account specified in the payer accountdata. Although not mandatory, these steps may be performed solely by afinancial intermediary. Inclusion of the PID control designation in thepayee payment packet distinguishes this set of embodiments from moreconventional methods of conveying a payment. As in embodiments discussedearlier, the payer surcharge may be zero.

Additional embodiments further include the step of transferring to thepayee account the payment amount minus a payee surcharge. The payeesurcharge may be zero, or it may be a sum of surcharges assessed byvarious entities.

Transferring the PID control designation as part of the payee paymentpacket facilitates confirming that the PID control designationcorresponds to the PID that has been registered in the name of the payerand is privileged to access the payer account in some embodiments.

In preferred embodiments, the PID authenticates that the user of thedevice is privileged to make a payment from the payer account bydetermining that a biometric sample collected from the user sufficientlymatches a biometric template associated with the payer account data. Asin other cases described above, the biometric template is stored locallyon the PID.

Another embodiment of the invention employs the transfer of a bearerfinancial instrument to convey a payment. Preferably, the bearerfinancial instrument (in most cases) is some form of a secure, privateelectronic certificate.

In some preferred embodiments, the bearer financial instrument takes theform of electronic script, as described in U.S. Pat. No. 6,122,625 toRosen, which is included herein by reference in its entirety. In otherpreferred embodiments, the bearer financial instrument takes the form ofdigital bearer cash, a model for which is described by Hetting a (“AMarket Model for Digital Bearer InstrumentUnderwriting,”<www.philodox.com/modelaper.html>, revised on Sep. 8,1998), which is included herein by reference in its entirety. Theparticular form of the bearer financial instrument is not critical toits use in the invention. However, preferred forms of bearer financialinstruments to be used with the invention can be transferred betweenparties without the direct involvement of a financial intermediary.

In such a method for conveying a payment, a PID authenticates theidentity of the payer. In this method, the PID is required only to be aportable device that authenticates that a user of the device isprivileged to use the device and has transference privileges to a bearerfinancial instrument stored on the PID. The bearer financial instrumentis then transferred to the payee, preferably by electronic means.Authentication of the payer is preferably accomplished by determiningthat a biometric sample collected from the user of the PID sufficientlymatches a biometric template associated with transference privileges ofthe bearer financial instrument.

Other embodiments of the invention relate to methods for a customer tomake a purchase from a vendor. As shown in FIG. 12, these embodimentsinclude a number of steps. A PID authenticates the customer identity1040. In this context a PID is a portable device that authenticates thata user of the device is privileged to use the device and is privilegedto request that a payment be charged to a customer account at a customerfinancial intermediary. Preferably after authenticating the customeridentity, the PID transfers customer account data and a customerfinancial intermediary address to an information processor, which is acomponent that receives signals from both the customer and the vendor1050. The vendor transfers vendor account data and a payment amount tothe information processor 1060. A vendor payment packet is formed 1070.The vendor payment packet includes the customer account data, the vendoraccount data, and the payment amount. Preferably after being formed, thevendor payment packet is sent to the customer financial intermediaryaddress 1090. As with the other related processes previously described,the data sent to the customer financial intermediary address need not besent there directly, but may be sent there via another entity. Such anembodiment is shown with the dashed lines in which the vendor paymentpacket is sent to the vendor financial intermediary 1080, which thensends the vendor payment packet to the customer financial intermediary1090. The customer account at the customer financial intermediary isdebited by the payment amount plus a customer surcharge 1100, and thevendor account at the vendor financial intermediary is credited by thepayment amount minus a vendor surcharge 1110. In some embodiments thecustomer and/or vendor surcharges are zero.

Preferably the PID authenticates the customer identity by determiningthat a biometric sample collected from the customer sufficiently matchesa biometric template associated with the customer account data.

Various embodiments of the methods for a customer to make a purchasefrom a vendor also include the optional steps indicated by dashed linesat the top of FIG. 12. These steps include selecting items for purchase1010, adding the selected items to an electronic shopping cart 1020, anddetermining the payment amount for the selected items in the electronicshopping cart 1030. In some embodiments the step of selecting items forpurchase is performed via a graphical user interface. In preferredembodiments, the graphical user interface is a simulated retail store.The simulated retail store may be rendered either as a two-dimensionallayout or may use perspective to render the simulated retail store inthree dimensions. In some preferred embodiments a holographic graphicaluser interface is used to facilitate the selecting of items forpurchase. In embodiments that employ a graphical user interface, theelectronic shopping cart may be maintained either on the PID untilcheckout or by the vendor. In preferred embodiments a record of thetransaction is maintained on the PID for later download to thecustomer's choice of personal accounting software.

In some embodiments, the customer physically moves through a store andselects items to be added to the electronic shopping cart. In preferredembodiments the physical items are retrieved from a storage facility atcheckout, i.e. when the customer has completed shopping and is ready tofinalize the purchases. In some embodiments, the electronic shoppingcart is maintained on the PID and is transferred to the informationprocessor at checkout. In other embodiments the electronic shopping cartis maintained by the vendor. In these embodiments the items are selectedfor purchase by sending a signal containing a customer identifier fromthe PID to a vendor electronic shopping cart processor. The electronicshopping cart processor maintains an electronic shopping cart for eachcustomer identifier. This information is provided to the informationprocessor at checkout. In preferred embodiments the customer identifieris the PID designator. Other embodiments use the customer name, or acustomer-chosen identifier to be the customer identifier. Still otherembodiments use a vendor assigned identifier as the customer identifier.In some embodiments, electronic shopping carts associated with multiplePIDs are merged at checkout. Such embodiments are useful when familieswith multiple PIDs go shopping. Merging their individual shopping cartsat checkout can facilitate gathering and loading the merchandise as wellas consolidating the finances.

To select items for purchase in a physical environment, the customer mayenter a code for each selected item into the customer's PID. However,such embodiments are tedious and error prone. To facilitate theselection of items in a physical environment preferred embodiments usean item designator. An item designator is a general device thatperceives a code on a selected item and transfers that code to the PID.For instance a bar-code reader that reads a bar code on a selected itemand transfers that code to the PID is an item designator. Amagnetic-stripe reader that reads a magnetic stripe on a selected itemand transfers that code to the PID is another example of an itemdesignator. A RF tag reader is yet another example of an itemdesignator. As the customer meanders through the physical environment,he/she selects items for purchase by using the item designator torapidly transfer the code for that item to the PID.

FIG. 13 shows another set of embodiments of the invention. Theembodiments in FIG. 13 involve methods for a customer to conduct atransaction. The methods include the steps of authenticating thecustomer identity to a PID 1240, sending customer account data to areceiver 1250, and receiving acknowledgment that the transaction wasapproved 1260. In this context the PID is a portable device thatauthenticates that a user of the device is privileged to use the deviceand is privileged to request that a payment be charged to a customeraccount at a customer financial intermediary. Preferably the PIDauthenticates the customer identity by determining that a biometricsample collected from the user of the personal identifying devicesufficiently matches a biometric template associated with the customeraccount data. Most preferably the biometric sample is a digit-print.

The dashed lines connecting the steps on the top of FIG. 13 show stepsthat may be added to obtain additional embodiments of methods for acustomer to conduct a transaction. These steps include the steps ofselecting items for purchase 1210, adding the selected items forpurchase to an electronic shopping cart 1220, and determining thepayment amount for the selected items in the electronic shopping cart1230. In some embodiments the electronic shopping cart is maintained onthe PID, while in other embodiments, the electronic shopping cart ismaintained elsewhere. Items may be selected through the use of agraphical user interface.

FIG. 14 illustrates embodiments of the invention that include methodsfor interacting with a simulated inventory. As used here, a simulatedinventory is visual representation of a catalog, index, directory, orother content. These methods use a PID to authenticate a user 1340. Asused here, a PID is a portable device that authenticates that the userof the device is privileged to use the device. In addition, the PID usedin these methods for interacting with a simulated inventory includes auser input module that receives inputs from the user. The inputs fromthe user to the PID are used to generate signals that allow the user totravel through the simulated inventory 1350. Travel is used here to meanthe movement of a cursor in the simulated inventory. Icons in thegraphical user interface represent items in the inventory. In variousembodiments, the icons are color, shape, or texture coded to visuallyindicate cataloging or other details of the item represented by an icon.Although in some embodiments, accurate graphical renditions of the itemsrepresented by various icons are used, in other embodiments moremeaningful information can be conveyed through symbolic renditions onthe icons. In embodiments in which the simulated inventory is accessedover a network, the bandwidth required can be reduced by preloadingicons and other resource-intensive objects onto the local computer. Thiscan be performed either as an initial download, or preferably byproviding these objects on a compact disk or other storage medium. Withthe resource-intensive objects residing locally, only codes thatindicate which objects are to be used and in what arrangement need to betransferred over the network.

In some embodiments, an inventory gatekeeper restricts access to thesimulated inventory. Only registered entities are allowed to enter. Inthese embodiments, the PIED communicates identity data to the inventorygatekeeper. The inventory gatekeeper checks a database to determine ifthe identity data is listed as a registered entity. If the identity datais listed as a registered entity, the inventory gatekeeper permitsaccess. Otherwise, the inventory gatekeeper denies access. In somepreferred embodiments, the inventory gatekeeper invites an unregisteredentity that is denied access to become a registered entity by followinga prescribed procedure. The procedure involves the disclosure ofidentity data that will be used to check for registration. The procedurealso may involve the payment of a fee and the disclosure of otherinformation.

Alternatively, some embodiments of simulated inventories are structuredto retain users' anonymity. The inventory gatekeeper, if one exists, mayonly require sufficient information to confirm registration and thenallow the user to chose a virtual cursor in such a way that the cursorcannot be traced to the user. This can be done by regularly purging theinventory gatekeeper of entry records or by any of numerous othermethods known to those skilled in the art. Such anonymity may be desiredfor instance during window shopping or for making price comparisons,where the user does not wish to be contacted or pressured by othersuntil he/she is ready to make his/her own decision with regard to if andwhat to purchase.

The database of identity data is not required to include only a singletype of entity. For instance, the database may include data thatidentifies PIDs, individuals, and organizations. These correspond toregistered entities that may be devices, people, or organizations. Theindividuals or organizations must have identity data that uniquelyidentifies them. In some embodiments the identity data comprise the PIDcontrol designation. Although not necessary, most preferably, the PIDcontrol designation is unique to each PID.

The simulated inventory has wide potential applications. For instance,in some embodiments it is used for inventory control in a factory orshop. In other embodiments the simulated inventory is that of a packagedelivery depot. Individual packages can easily be tracked in such asimulated inventory. Other applications include inventories oflibraries, lost and founds, and sperm and egg banks. In addition tothese applications, simulated inventories of shopping environments cantransform the shopping experience.

In preferred embodiments, the simulated inventory is a shoppingenvironment in which those entities that are allowed access arepermitted to shop. For example, in various embodiments the simulatedinventory is a grocery store, a department store, a parts warehouse, anautomobile showroom, a boatyard, or a neighborhood with homes for sale.In yet other embodiments, other simulated sales environments, such as ashopping mall are used.

As shown in FIG. 14, the dashed lines connect optional steps that aremost useful in simulated sales environments. For instance, the method ofinteracting with the simulated inventory preferably includes the step ofselecting items for purchase from simulated inventory 1310. Preferablythis is accomplished by overlaying a cursor on an icon in a graphicaluser interface and optionally triggering the selection by depressing anactivation button on the PID. Multiple quantities of the selected itemare preferably indicated by multiple depressions of an activation buttonon the PID. Other methods of indicating multiple quantities, such asthrough the use of keyboard entry or a pull-down menu are optionallyprovided. Indications of the selected quantity are optionally indicatedon the PID, the icon, or both. The selected item is preferablyhighlighted when selected. In cases of three-dimensional graphical userinterfaces or holographic graphical user interfaces, highlighting, orsome other feedback means for indicating selection is particularlyuseful because of the possibility of misconstruing depth relationshipsbetween the cursor and the icon.

As shown in FIG. 14, in preferred embodiments in simulated salesenvironments, the method of interacting with the simulated inventoryfurther includes the steps of adding selected items to an electronicshopping cart 1320, and determining a payment amount 1330. In preferredembodiments the step of selecting an item for purchase 1310 also addsthe item to the user's electronic shopping cart 1320. However, in otherembodiments the user must take additional action to add selected itemsto an electronic shopping cart.

Some preferred embodiments include a step of certifying paymentcapability 1345. Certifying an entity's payment capability before theyare allowed entry into the simulated inventory reduces the cost oftracking entities that have no intention or capability of making apurchase. Various embodiments certify payment capability differently. Insome environments it may not be necessary or appropriate to certifypayment capability, i.e., either due to proven need for the productbeing sold (e.g., grocery stores, fast food), or the relative low costof the inventory, or the need to not challenge customer prospects, etc.Thus, this step 1345 is optional. Of course, any vendor can organizetheir selling operation based on their notion how to best serve theircustomers.

In other preferred embodiments, payment capability is certified byestablishing an account to which the cost of purchases is charged. Insome embodiments the account owner is required to maintain a specifiedbalance (either by maintaining a minimum positive cash balance or by notexceeding a maximum credit limit) in the account in order to continuemaking purchases from any vendor's simulated inventory. In someembodiments, this is done by provisionally debiting the account as itemsare selected for purchase. If a purchase would result in the account notmaintaining the specified balance, the purchase would be prohibited. Inpreferred embodiments, the prohibition would be removed if additionalfunds were added to the account, the specified balance were modified, orpreviously selected items were returned in amounts sufficient to enablethe new purchase without while still maintaining the specified accountbalance. Details of account management can vary widely. For instance,accounts can be standard credit-card accounts, standard bank accounts,or special-purpose accounts for use with one or more simulated inventoryofferings from one or more vendors.

In other embodiments, payment capability is established through a creditcheck, or some form of credit instrument, bond, or other debt or creditinstrument from a financial intermediary. These forms of certifyingpayment capability would be appropriate for simulated inventories ofhigh-priced items. In particular, houses, automobiles, boats andairplanes could be viewed with such a simulated inventory. Although theprospective purchaser of such high-priced items would probably wish toview the actual item before finalizing the purchase, numerous candidateitems could be screened through the simulated inventory before choosingwhich ones deserve a physical visit.

To reduce the possibility of fraud, in preferred embodiments, the PIDrepeatedly authenticates the user. The details of the repeatedauthentications vary with particular embodiments. For instance, therepeated authentications can be either at regular or at irregularintervals of some metric. The metric can be either time or some othermeasure.

Unlike many computer and on-line shopping models currently in use,various embodiments of the simulated inventory are more nearly likeshopping in a shopping mall having multiple stores, rather than a singlestore. In some embodiments storeowners would essentially rent space fromthe provider of the simulated inventory. For the shopper, variousembodiments permit the use of a single electronic shopping cart for allpurchases. In preferred embodiments the electronic shopping cart tracksfrom which store each item was selected. Preferably a single checkoutprocedure properly credits each of the merchants for items selected fromtheir store and separately obligates each of the merchants for providingthe selected goods or services. Such an approach frees the consumer fromgoing through multiple checkouts and allows the consumer to easilyreturn items selected from one merchant if a better or less costly, orotherwise preferred item is found in another merchant's store in thesimulated shopping environment.

As is clear from the above descriptions, invention described hereinentails many possible embodiments.

The above description and drawings are only illustrative of preferredembodiments that achieve the objects, features, and advantages of thepresent invention, and it is not intended that the present invention belimited thereto. Any modification of the present invention that comeswithin the spirit and scope of the following claims is considered partof the present invention.

In the following claims, the use of the articles “a” and “an” should beinterpreted to mean “at least one” of the designated element unless theclaim specifically limits the number of the designated element. The useof the phrase “at least one” in any claim is intended to emphasize thepossible plurality of the specified element, but its use does not limitthe possible plurality of other elements specified with “a” or “an.”

simulated inventory reduces the cost of tracking entities that have nointention or capability of making a purchase. Various embodimentscertify payment capability differently. In some environments it may notbe necessary or appropriate to certify payment capability, i.e., eitherdue to proven need for the product being sold (e.g., grocery stores,fast food), or the relative low cost of the inventory, or the need tonot challenge customer prospects, etc. Thus, this step 1345 is optional.Of course, any vendor can organize their selling operation based ontheir notion how to best serve their customers.

In other preferred embodiments, payment capability is certified byestablishing an account to which the cost of purchases is charged. Insome embodiments the account owner is required to maintain a specifiedbalance (either by maintaining a minimum positive cash balance or by notexceeding a maximum credit limit) in the account in order to continuemaking purchases from any vendor's simulated inventory. In someembodiments, this is done by provisionally debiting the account as itemsare selected for purchase. If a purchase would result in the account notmaintaining the specified balance, the purchase would be prohibited. Inpreferred embodiments, the prohibition would be removed if additionalfunds were added to the account, the specified balance were modified, orpreviously selected items were returned in amounts sufficient to enablethe new purchase without while still maintaining the specified accountbalance. Details of account management can vary widely. For instance,accounts can be standard credit-card accounts, standard bank accounts,or special-purpose accounts for use with one or more simulated inventoryofferings from one or more vendors.

In other embodiments, payment capability is established through a creditcheck, or some form of credit instrument, bond, or other debt or creditinstrument from a financial intermediary. These forms of certifyingpayment capability would be appropriate for simulated inventories ofhigh-priced items. In particular, houses, automobiles, boats andairplanes could be viewed with such a simulated inventory. Although theprospective purchaser of such high-priced items would probably wish toview the actual item before finalizing the purchase, numerous candidateitems could be screened through the simulated inventory before choosingwhich ones deserve a physical visit.

To reduce the possibility of fraud, in preferred embodiments, the PIDrepeatedly authenticates the user. The details of the repeatedauthentications vary with particular embodiments. For instance, therepeated authentications can be either at regular or at irregularintervals of some metric. The metric can be either time or some othermeasure.

Unlike many computer and on-line shopping models currently in use,various embodiments of the simulated inventory are more nearly likeshopping in a shopping mall having multiple stores, rather than a singlestore. In some embodiments storeowners would essentially rent space fromthe provider of the simulated inventory. For the shopper, variousembodiments permit the use of a single electronic shopping cart for allpurchases. In preferred embodiments the electronic shopping cart tracksfrom which store each item was selected. Preferably a single checkoutprocedure properly credits each of the merchants for items selected fromtheir store and separately obligates each of the merchants for providingthe selected goods or services. Such an approach frees the consumer fromgoing through multiple checkouts and allows the consumer to easilyreturn items selected from one merchant if a better or less costly, orotherwise preferred item is found in another merchant's store in thesimulated shopping environment.

As is clear from the above descriptions, invention described hereinentails many possible embodiments.

The above description and drawings are only illustrative of preferredembodiments that achieve the objects, features, and advantages of thepresent invention, and it is not intended that the present invention belimited thereto. Any modification of the present invention that comeswithin the spirit and scope of the following claims is considered partof the present invention.

In the following claims, the use of the articles “a” and “an” should beinterpreted to mean “at least one” of the designated element unless theclaim specifically limits the number of the designated element. The useof the phrase “at least one” in any claim is intended to emphasize thepossible plurality of the specified element, but its use does not limitthe possible plurality of other elements specified with “a” or “an.”

1. A method, comprising: receiving biometrically-authenticated dataassociated with funds of a user from a personal identification device ofthe user, the biometrically-authenticated data excluding biometricinformation of the user and being based on biometric information of theuser authenticated by the personal identification device; and sending anacknowledgement to the personal identification device when the funds ofthe user have been verified based on the biometrically-authenticateddata associated with the funds.